Hacker News Reader

Comment by et1337 | Hacker News Reader

1. Ditch Ruby. Node or Python with asyncio work fantastic with WebSockets. Use a greenlet-enabled database connection pool.

2. Use HTTP for traditional request/response tasks. Use WebSockets to push realtime notifications to clients.

3. Have your clients auto-retry their WebSocket connections in the background. Show an indicator of degraded service when this happens. When a new WebSocket connects, blast a complete state update to it to take care of any missed messages. Now you can easily load-balance your clients.

(my two cents, YMMV, etc.)

View on HN

Yes, yes, and yes, you nailed it. The author of the article seems to have difficulty separating "problems specific to WebSockets" and "specific problems I have."

People who say "REST is dead, AJAX is dead, HTTP headers are dead, all hail the new sockets" are wide-eyed fanatics and this article is a useful corrective to them, but it's definitely not an even-handed analysis.

There are too many problems with the article to do a line-by-line rebuttal, but the one that was most silly for me was "what if a user has multiple tabs open, oh noes!" It's trivial to implement a session id then disconnect the inactive tab(s), and has been for a long time.

On the other hand, his recommendations in the comments are pretty solid, so he's not completely off...

Better yet, use C#/ASP.NET with SignalR. SignalR automagically negotiates the best underlying technology (whether that's long polling, SSE, Web Sockets, or whatever), and provides you with a nice little abstraction layer over the top. And it scales quite nicely.

You do realize that socket.io (node) did it first?

I'm all for SignalR and even like C#/ASP.Net (and MVC). That said, there are other factors to consider when developing/deploying an application in .Net ... the abstractions needed for testable C# are particularly annoying imho.

In what ways is asyncio in python a better solution than eventmachine in ruby? They seem like incredibly similar designs.

I know it's an area of some debate, but at least to me, greenlets are easier to write and understand than callbacks, by an order of magnitude.

Greenlets work especially well with Python's "with" statement. You can have a database pool like this:

  with (yield from pool.connection()) as conn:
      users = yield from conn.query('select * from users')
  for user in user: ...

Now your database connection is only locked up inside the "with" statement, and the whole thing is asynchronous even though it's written in a synchronous style.

You can do this in Ruby with Fibers and people have been doing so for the past 6 or 7 years.

We created a WebSocket client wrapper library to make your third point easier to deal with. It handles only the connection freshness judo and nothing else, and doesn't require a special server or anything. Maybe people here find it interesting: https://github.com/fanout/websockhop

I've just started using this too, not much real world experience but in case it's useful to someone: https://github.com/joewalnes/reconnecting-websocket

If you have to use Ruby and using Node along with Ruby isn't an option I would be looking at RabbitMQ and Bunny.

Reply on news.ycombinator.com