by strzalek on 12/30/15, 12:46 PM with 110 comments
by spoiler on 12/31/15, 1:32 PM
So, to me it feels like the 1-connection-per-tab feels like saying "someone launched 50 instances of an executable and it opened 50 TCP connections".
Examples of where I think it's acceptable/recommended to use Web Sockets include /(video|audio)?/ chats, multiplayer games, collaboration tools, etc. Stuff that requires real-time notifications.
Does a discussion platform require that time precision? I doubt it (frankly, I think WebSockets would give a too high "temporal resolution" unless there were proper delays in place which just complicates the implementation, but that is actually irrelevant here).
by et1337 on 12/31/15, 4:41 PM
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.)
by Maarten88 on 12/31/15, 1:09 PM
My opinion now is that websockets are an all-or-nothing proposition. And I have gone all-in. My latest project has:
- websockets-only api (except a some image uploads and oauth/login)
- https-only
- single page app, central store with observable data, using a single connection servicing the whole application
- using SignalR (supports fallbacks for IE9 and old Android)
- Actor-based backend (Orleans)
This stack feels like the future to me, but I've had to learn a lot of new things. It's quite different from the web development that I've done over the past 15 years. Overcoming the connectivity issues mentioned in the article is only the first step. Websockets need another type of backend to make sense: Actors. I've had many challenges with the async realtime behaviour of the system, deadlocks, etc.
But now that everything is working and I have some grip on it, I can't imagine going back to a rest/database/cache web architecture.
by mchahn on 12/31/15, 4:49 AM
On my current project I'm using server-sent-events (SSE) for single-duplex pushing to the client. I'm using AJAX calls for the other direction. So far the experience has been awesome. Very light-weight and performant. Just a dozen lines of code on the client with no framework.
Caveat: Doesn't work with IE. A polyfill is required. I am very lucky on this project that I don't need to support IE.
by jzwinck on 12/31/15, 12:45 PM
If using epoll and kqueue directly is not your cup of tea, just use libuv or one of the other wrappers. It's not hard then. I know because I'm a native epoll user but recently helped someone on Stack Overflow and it took me maybe fifteen minutes to write a working libuv server having never used libuv before.
by Rauchg on 12/31/15, 7:29 PM
Most people that implement WebSocket directly end up re-inventing a protocol on top of it. This is necessary because the "onmessage" handler of WS is not something you can really build an application on. And then you'll have to add reconnection and exponential delays after that.
If you just want to use HTTP polling, which as the author suggests is perfect for most applications (perhaps not games), you can simply do: `io('http://myhost', { transports: ['xhr-polling'] })`.
by atemerev on 12/31/15, 12:44 PM
In all webapps, there are buttons. In some cases, clicking a button requires an action on the server, and therefore a roundtrip. If Websocket connection is established (you don't need more than one for everything), there is no overhead. With HTTP, you need to build a request every time.
Websocket plays nice with modern reactive streaming architectures. You send stream of events, you receive stream of updates. Everything is transparent and immutable and asynchronous.
If there is a connection loss, you are immediately notified and can move your app to offline mode. This is problematic with HTTP.
Websocket enable web apps comparable with native apps. HTTP apps will always feel less responsive to user actions.
by amelius on 12/31/15, 2:31 PM
[1] https://productforums.google.com/forum/#!msg/chrome/-NVlnMqx...
by bradgessler on 12/31/15, 1:48 PM
I also gave a talk about it at RailsConf (http://www.bradgessler.com/talks/streaming-rest/) and learned that RabbitMQ as a backend isn't a great idea. Feel free to ask questions if you want me to dive into more specific points.
by andyhoff on 12/31/15, 12:40 PM
Web Sockets are great to bring some of the more heavy duty apps from Desktop/TCP to the web. PubNub, Pusher and the likes show it is possible to achieve reasonable scale.
by k__ on 12/30/15, 10:17 PM
I mean, this isn't really a new kind of tech. It reads a bit like someone who rode horse his whole life and found out that there are cars and now fears about all the dangers they could bring.
by legulere on 12/31/15, 1:08 PM
by mmaunder on 12/31/15, 4:28 PM
I can't think of any reason why I wouldn't use node.js on the server-side for web sockets. It obviously uses epoll() and you really need an event language to be comfortable writing an application that manages a large number of concurrent connections. Ruby for this makes me shudder - sorry it just feels like a square peg forced into a round hole that's late to the party.
by mstade on 12/31/15, 3:27 PM
Server-sent events are a great tool for streaming server-to-client data where other more specific media types (i.e. audio/video) doesn't fit the bill.
by colmmacc on 12/31/15, 4:53 PM
The problem is that establishing a web socket, especially when using SPDY or HTTPS (which is typical), is much more expensive than maintaining a connected one. So a service will typically see a steady creep up in the number of connections, with a relatively low number of new connections per second, and it's probably been tuned for massive levels of concurrency, and that's all manageable. But then the service has a blip of some kind all of a sudden all of those web socket clients try to connect at the same time; disaster.
At that point the service is incredibly overloaded, so many connections fail, which results in retries, which makes matters even worse still and fuels a vicious cycle. That situation might self-stabilize if browsers implemented exponential back off, but that's not typical either. So the service remains hosed until some kind of blood letting can be done to let clients back in at a manageable rate.
Extremely pernicious, and something I've seen several times. When scaling web-sockets, it's important to ask: can I handle all of these clients reconnecting at the same time?
by xorcist on 12/31/15, 3:52 PM
by fideloper on 12/31/15, 1:42 PM
Those still in favor / find themselves disagreeing, while not necessarily always saying explicitly, seem to be those just starting out on their websocket journey.
At least, that's how it seems to me.
by wolframhempel on 12/31/15, 1:04 PM
by jkarneges on 12/31/15, 7:06 PM
Pushpin also supports WebSockets, but the long-polling capability is first class and not an afterthought.
by Matthias247 on 12/31/15, 12:08 PM
Yes, Websockets are hard to implement, and most implementations that are floating around (e.g. on github are horribly broken). But the same probably applies to good HTTP and especially HTTP/2 implementations too!
I also totally agree that web sockets make load balancing and proxying more complicated than stateless HTTP requests.
But I still think that Websockets have their place. They are some kind of more basic building block (like TCP), on which you can build your own protocol with totally different semantics. If you only build some request/response protocol on top of it you probably have not gained much - but still it would be different from HTTP in the way that message ordering is guaranteed. If you only need events from the server to the client you could use SSE, but if you need to add some dynamic subscribe/unsubscribe functionality you would need some additional HTTP [POST] calls. You could get the idea that you use one SSE endpoint per topic and treat the stream disconnect as an unsubscribe, but as long as you can't rule out that you have any non HTTP/2 clients it won't work because of the connection limit in browsers. I also benchmarked that approach with node and golang http/2 against my websocket based protocol and achieved only a throughput of about 10% of the websocket based solution.
All in all I currently think that currently one should favor pure HTTP if scaling is a big issue and if most state is anyway persisted in some distributed databases.
If only a single server is the remote peer, the state is not necessarily persisted per client, a combination of RPC and event distribution semantics is needed, message ordering guarantees are necessary or high realtime characteristics are needed then websockets are a very powerful option seriously needs to be considered.
My personal use-case is forwarding data from automotive realtime bus systems into web-based user interfaces and I had great success with using websockets to achieve this. Although I'm still also looking into HTTP/2, because it really has some interesting properties.
One other thing I would like to add: One comment in the article mentions to always prefer websocket frameworks like socket.io or signalR. What you should take into account is that by using one of those frameworks you are also binding yourself to a specific technology stack (node, C#, ...), if you are not willing to reimplement the protocols. If you use your own well-specified protocol or another well-specified higher level protocol (like WAMP), then you are not bound to specific technologies for your client and server applications. Therefore I always opt to go that way if long maintenance, open APIs or good interoperability are desired.
by geoffroy on 1/1/16, 11:01 AM
by iamleppert on 12/31/15, 11:06 PM
It's a technology like anything else. See if it meets your requirements, if it does, great, go for it and learn along the way. If not, stick to regular connections.
Case closed.
by warfangle on 12/31/15, 7:09 PM
by ashearer on 12/31/15, 6:37 PM
Takedown articles tend to share similar characteristics. Many are on a mission that emphasizes the negatives of their subject, even minor ones, while overlooking the positives and handwaving away problems with the alternatives. They set the bar higher for the subject by finding issues that it shares equally with its alternatives, and presenting them as damning evidence against it (since users may expect it to be better and be disappointed). The specific alternative that's held up as superior to the subject varies from point to point--no one alternative is actually superior in all points. They may even acknowledge that many of their arguments are weak, but make up for it in volume.
In its favor compared to such articles, this one does make some attempts to be evenhanded, but they're overpowered by the dramatic language used to make the opposing points. (For example, the brief acknowledgement that point 1 is the "weakest argument against WebSockets" is surrounded by phrases like "wreak havoc", "weird stuff will definitely happen", "rogue proxies will break you").
This article puts itself squarely in the category of "the case against".
A more balanced article might discuss:
1. The situations where you might want to avoid WebSockets (no HTTPS, IE 8 & 9 compatibility, a server platform without good support, or where they don't provide actual usability benefits).
2. Pitfalls that both long-polling and WebSockets share (you have to handle reconnections and synchronize state, be mindful of the open connections when reconfiguring a load balancer, account for server load, and use a server platform with good support for long connections).
3. Differences that can be viewed just as reasonably in WebSockets' favor, which the article counts as negatives. Example 1: Resynchronizing state after a network interruption is necessary with both long-polling and WebSockets, though the article notes it as a WebSockets disadvantage. The reconnection process is explicit with WebSockets, but some long-polling libraries make it very easy to ignore these events, leaving the client out of sync. Example 2: WebSockets aren't limited to 6 connections, unlike long-polling, so you won't get a silent connectivity roadblock on some tabs when the user has several of them open.
4. Advantages unique to WebSockets: responsiveness is improved due to not needing to send HTTP headers with every request and response, and the underlying TCP connection is already warmed up; load balancing and redundancy may be simplified by no longer requiring a session affinity mechanism (because the connection itself preserves short-term state, which can be re-established by the client transparently to the user in the rarer event of reconnection); less overhead than long-polling; a whole class of problems resulting from cookies as the sole mechanism of state transfer is avoided; the same protocol can be implemented simply and efficiently by native mobile apps.