Hacker News Reader

Comment by mootothemax | Hacker News Reader

Ah, the good old "I could build StackOverflow in a weekend" line of thinking - I'm sure we've all been there.

There's a world of difference in building a photo sharing app with XXX,XXX users vs. building a chat app with XXX,XXX users.

When you do anything that involves chat or that level of concurrency, surprises will bite you in the behind, multiple times, even if you desperately try to use as much existing software as possible.

(as anyone who's taken a look at ejabberd, thought it'll play nicely, and then load tested their code will tell you)

Frankly, PHP vs. Rails vs. Node[1] vs .Net vs Java will be the least of your troubles.

[1] I do fear that the author is going to find a nasty surprise or two for themself regarding Node's performance issues

View on HN

Though, using a specialized language like Erlang can make it possible to run WhatsApp on only 50 engineers (in 2015). I agree with the OP that choosing a stack like Rails can kill your Pokemon Go related MVP pretty quickly (I'm a huge Rails fan myself, but would definitely use Node.js for something like that).

Depending on what kind of app the Rails stack is operating...it would follow the same exact pattern as Chat vs Photo Sharing in nodeJS as in the article. A Rails app running a JSON API server would do pretty well, and basically has the same boilerplate as the node hackathon thingy built in, plus a few extra gems.

Except that it's an order of magnitude slower than some other tech.

Except it will collapse under it's own weight too quickly.... Rails is a pretty bad core for a chat engine.

> make it possible to run WhatsApp on only 50 engineers

Frankly, I'm sure Erlang is great, but with 50 full time skilled engineers I'm pretty sure you could run WhatsApp on almost anything.

Ask Twitter team; they may have a different story.

The largest explosion in their user base came when I think they were at something like ~11 engineers, and from what I've heard the largest additions to their engineering team came on the frontend side, not the backend.

I'd probably do the first gen core chat in Node, and write everything else to leverage a cloud provider's infrastructure of choice.... Google, Azure and AWS all offer similar services which include bigtable, blob/file storage, some hosted SQL variant, document search engine, and some form of queuing service.

The hard part is routing messages, and looking at some of the messages, seems to be location based chats... probably could use geohashing for sending messages to channels, the hash level you are at, plus the surrounding 8 hashes.

Breaking up the server instance that a given chat connects to based on location hash would probably work out well enough. I'm not specifically familiar enough with the app... But it seems to me that channel growth and routing are the harder things in this at the scale of millions of users.

Reply on news.ycombinator.com