[clone1018]

We use WebSockets in two regards: handling live page updates via Phoenix Live View for users (eg: real time chat messages, viewer count, etc) and as a transport medium for our real time API. The former is very easy to handle because for the most part users are navigating around pages which can terminate the ws connection and creates a new one (though most of the times not). The advantages Live View provides us is not having to write duplicated logic in the client & server, and instead just push data to users and their browser automatically reflects the changes.

However the latter use offers very powerful benefits with some difficult downsides. On the positives side you get a "real time" API to work with, and you can handle events as they happen and send updates back to them. In some cases our API users can even respond to a chat message faster than we can!

Since WebSockets are virtually just a transport, it's up to you to write a protocol for handling heartbeats, authentication, and communication. In addition when you have a horizontally scaled service it can make balancing the WebSocket connections a bit more challenging since they are long lived. Deployments are even more inconvenient since (in our case) we disconnect the WebSocket consumers whenever a server is restarted for the update. It can also be difficult to fully measure and understand how many WebSocket connections you have open, and how many resources they are consuming. It's important to really push down the number of computations you are doing for users who are subscribed to the same topics so that when you send out 10,000 updates with the same message it's just the text being sent, not 10,000 DB queries :D.

[nlitened]

> it can make balancing the WebSocket connections a bit more challenging since they are long lived. Deployments are even more inconvenient since (in our case) we disconnect the WebSocket consumers whenever a server is restarted

May I suggest that the solution could be to design your WS protocol to be reconnect-friendly, like the Phoenix LiveView protocol? Maybe make a protocol which assumes and expects that a connection may be dropped by any side at any time, with robust context-restoration API such as “full snapshot” or “all updates since event ID”

[ddoolin]

I think your last paragraph is a good point for using services like the OP. All three of the examples you mentioned are already solved. Granted, you're buying into their paradigm particularly regarding communication model but that's a small price to pay for the upsides.

Disclaimer: we've been using Ably for years and their service and reliability has been outstanding, and we have worked closely with their engineers and I've found their expertise to be above what you may expect from experience with other company's support personnel.

[mwcampbell]

I'm generally reluctant to add dependencies on third-party services such as Ably in the core application, because that would add another barrier to providing an on-prem deployment option, or even allowing a customer to deploy on their own AWS infrastructure instead of ours. I'm actually contemplating this decision right now for a new product.

[mathgladiator]

This is one reason I'm making my up and coming SaaS entirely open source, so you can run a clone in any environment: http://www.adama-lang.org/

[ddoolin]

That's an understandable concern you have IMO. As with anything, the solution should fit the problem. Those aren't issues for us but I can empathize with the concern with adding more external services. In our case, we actually tried to implement our own socket "stuff" in one project and ended up switching that to Ably as well just because it was very difficult to both implement and debug over AWS.

[matt_oriordan]

I am surprised to hear about on-prem deploys when the direction of travel is towards serverless/cloud solutions that don't require orchestration. Out of interest, why is on-prem so important for your use case? Separately, I'd be interested in how you'd view that decision if there was a less scalable but mostly fully functioning open source version of the third-party service you could deploy if you needed to?

Matt, co-founder of Ably

[nurettin]

Sorry to butt in like this, but cloud is just one direction, not the direction. Pretty much any company that values their privacy and independence will want on-prem. This should not come as a surprise to anyone.

[mwcampbell]

For one of my company's products, we're already working with a security-sensitive customer on a deployment on their own AWS infrastructure (in their own VPC). This customer wouldn't be comfortable using our public cloud deployment unless we get a SOC2 certification or similar. For the product I'm developing now, some potential customers will definitely want to keep it physically located within their corporate network. That's all I can say publicly.

If there was a less scalable, but still mostly functioning open-source substitute for Ably, then I'd be way more comfortable using Ably in the main public cloud deployment.

[matt_oriordan]

I understand the SOC2 requirement, which is why we're SOC2 compliant. A long and painful process, but one that has opened up opportunities like the one you said would otherwise require an on-prem installation. We have in fact also got some VPN-like links (AWS PrivateLink) with customers who are particularly sensitive to security and data leaving their network, and that coupled with SOC2 has made it possible.

> If there was a less scalable, but still mostly functioning open-source substitute for Ably, then I'd be way more comfortable using Ably in the main public cloud deployment.

Thanks for the feedback, I will pass on to the product team!

[drunkenmagician]

Where I'm based (in Asia) on-prem is definitely a need for some sectors. Banks and financial institutions, healthcare, government etc. They may not need it for all solutions, but they sure want to know they can have it if needed. Its the very reason we (SaaS company) make sure we don't rely on any cloud PaaS services for our product.

[matt_oriordan]

Thanks ddoolin. I am not sure which company you are, but I appreciate your comments and even more happy to hear you feel we're doing a fantastic job! You've sort of encapsulated why we exist: we know software engineers can build and run all sorts of things on their own i.e. we're not the only option from open source solutions to custom builds. However, we built Ably to be the easiest, most scalable, and reliable realtime option which for developers that removes complexity and helps them manage costs as they grow (pay for what you use).

Matt, co-founder at Ably

[lvass]

>we disconnect the WebSocket consumers whenever a server is restarted for the update

Isn't avoiding this the main selling point for BEAM? As in Erlang: the movie. Can't that be done with websockets?

[sb8244]

You could totally do this with BEAM, via hot swapping. The WebSocket processes don't really change, it's the implementation of what happens when messages comes in that changes. So you'd setup your hot swap with this in mind. (The connection processes stay connected and the behavior module is swapped out?)

However, hot swapping is not super common in practice. Mainly because it's added complexity that most people can live without.

[clone1018]

Right, this is the comment I was going to make as well. It's certainly possible, but there's tradeoffs (mainly around complexity) to code hot-swapping. We haven't implemented it because restarting servers to upgrade code helps everyone prepare for when servers go down for unexpected reasons, or so I like to think :P!