4 ms·
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
by et1337 11y ago
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.)
- jkarneges 11y agoWe 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 https://github.com/fanout/websockhop
- matt2000 11y agoI'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 https://github.com/joewalnes/reconnecting-websocket
- Dr_tldr 11y agoYes, 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...
- shams93 11y agoIf you have to use Ruby and using Node along with Ruby isn't an option I would be looking at RabbitMQ and Bunny.
- smithkl42 11y agoBetter 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.
- tracker1 11y agoYou 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.
- sanderjd 11y agoIn what ways is asyncio in python a better solution than eventmachine in ruby? They seem like incredibly similar designs.
- et1337 11y agoI 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.
- rubiquity 11y agoYou can do this in Ruby with Fibers and people have been doing so for the past 6 or 7 years.