How scalable are server-sent events in Rails?

If Puma creates a new thread for each connection, don't use it. Not only do you plan for hundreds of thousands users at once but provided it's going to be a web application, users can have multiple instances open in multiple browser tabs. Even the SSE specification warns against the "multiple tabs" problem because browsers may have their own limits of the number of simultaneous connections to one host:

Clients that support HTTP's per-server connection limitation might runinto trouble when opening multiple pages from a site if each page hasan EventSource to the same domain. Authors can avoid this using therelatively complex mechanism of using unique domain names perconnection, or by allowing the user to enable or disable theEventSource functionality on a per-page basis, or by sharing a singleEventSource object using a shared worker.

Use an evented server where connections do not block. The above-mentioned gevent, something built on Node JS or something else in Ruby (which I don't know and thus can't recommend anything).

For other readers who land on this page and might get confused, Rich Peck's answer is wrong. Server-Sent Events don't rely on long polling, nor do they send requests every couple of seconds. They are long-lived HTTP connections without the need to reopen the connection after every event. There are no "constant requests to the server".

About the Puma approach using one thread per client, given you have a limit of 16 threads per server, maybe you can think about horizontal scaling your servers? Like, if you deploy to amazon and set up Elastic Load Balancing + Auto Scaler, your infrastructure shoud be able to accept as many clients as needed. Or am I wrong ?And I guess the multiple tabs problem could be overpassed by forbidding multiple connections per client, displaying an appropriate error message if the user opens a new tab.

I'm not sure about the threading issue, but from experience, I can give you some idea about SSE's

SSE's

The most important thing to consider is that SSE's depend on Javascript long polling, meaning it will continue to send requests to your server every few seconds, in an attempt to "listen" for updates

Check it when you set up an SSE eventlistener - it will send requests every couple of seconds to your server. The connection will not be perpetual

There's a great discussion about this here: What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?

--

The problem here, at least to me, is that if you're sending constant requests to your server, it's not only going to be inefficient, but also very constricted in terms of functionality

As with the pub/sub pattern, if you want to deliver "live" updates to your users, you'll want to firstly have some sort of authentication (which I believe SSE's don't provide), as well as ensuring you have particular "channels" for those users to receive updates for them

Having said that, there's a great post about creating a chat application with SSE's here:

I've only ever used SSE's for sending site-wide updates, for the simple fact that I'd prefer to have a single connection (websocket), which I can authenticate & populate with a user's specific data

Pusher

We use websockets wherever we can

The trick, though, is that you can use a third-party websock provider, like Pusher. I'm not affiliated with Pusher in any way; we have used them for a number of projects - EPIC service

Using Pusher, you'll be able to accept & deliver specific messages to the users on your site without having to set up your own websocket server. You just connect to Pusher's service with the same JS setup (eventlistener), which will only connect once to the Pusher service:

You can then send updates to your users by just "pushing" to the Pusher API. We have set this up tentatively with an analytics app we are in the process of building out here

To answer your question, I don't know how scaleable SSE's are

I tend to take lead from the "big" internet companies (as a demonstration on how to do it "right"), and I've yet to see any of them favour SSE's over websockets. I may be wrong, but they all prefer websockets