Hi, I'm the main author of SocketCluster. SC does support multi-node clustering; in fact, you can deploy with a single command and scale with a single command. SC has been able to auto-scale on Kubernetes for almost one year now. See https://github.com/SocketCluster/socketcluster/blob/master/s...

You're right that neither SC not Deepstream support long polling fallbacks but there are some very good architectural reasons for this. Both SC and Deepstream used to support HTTP long polling fallbacks via engine.io in the past but both projects independently decided to stop doing it after years of experimentation and feedback.

Now that WebSockets are well supported in all major web browsers and HTTPS has become even more prevalent (so corporate proxies are no longer a problem), the extra load balancing complexity, performance costs and the DoS vulnerabilities of long polling are no longer worth it.

on rereading my comment, I realize I was ambiguous. I meant that phoenix channels was the only multiclustering solution or websockets that has long polling support.

I can definitely appreciate the additional complexity of supporting the fallback. I imagine that elixir's OTP and STM functionality lowers the bar for handling the extra state management across multiple nodes.

Corporate proxies are still an issue. Now they have something like SSL inspection proxies. Essentially the proxies can see everything even if it is https. And websockets does not work with these proxies even over https.

These do exist but they are not common; it's an insignificant proportion of users; in a representative sample of all web users, you're probably more likely to encounter users with JavaScript disabled in their browser altogether than users who are being snooped on and restrained by their company in this way.

Also, for these proxies to work, the company has to have access to the user's machine to install their own root CA certificates onto it; so generally, this issue is limited to corporate workstations and not BYO mobile devices and personal devices.

It's only a big problem if you want to support users from a specific company which happens to be a major customer (like a corporate SaaS solution); but if that particular company is such a big user of your product then they can always change their proxy policy to allow WebSockets from your domain.

I think that there are few enough of these companies that they should be the ones to adapt to new technology and not the other way around. It's important for open source projects and companies to set positive standards and not always bend to the will of corporations; especially when it comes to ethically-questionable practices.

You can still offer a REST API without real-time features for those users. The cost of long-polling is that bad. It's very easy to DDoS.

Phoenix Channels are great, but they're totally not a replacement for Firebase. You need to do a lot of coding on top of Channels to get what Firebase offers you.

Not that that takes anything away from your argument, but given that this topic is about Firebase, readers could get the impression that it offers the same.

That said, I like Phoenix Channels too, and the long polling support is a must-have for us. The "very good architectural reasons" for not doing this, as quoted by @jondubois in a sister comment, are nice, but if that means that 10% of our audience can't use our product then that's a show stopper. I love that Phoenix takes these cases seriously.

That said, Phoenix Channels are a mess when it comes to documentation and terminology. It's built on only two terms, "socket" and "channel", both of which mean 2 to 3 different but related things.

(background: at https://talkjs.com we recently moved our realtime stuff from Firebase to Phoenix Channels)

Dokku implementation for any Linux server hosted locally or in the cloud. Not affiliated just really like the product.

https://ashleyconnor.co.uk/2016/03/06/deploying-a-phoenix-ap...