4 ms·

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

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.

ddoolin 5y ago
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 5y ago
  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.
  - matt_oriordan 5y ago
    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
    - deleted 5y ago
      [deleted]
    - mwcampbell 5y ago
      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 5y ago
        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!
lvass 5y ago
>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 5y ago
  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 5y ago
    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!
nlitened 5y ago
> 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 5y ago

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 5y ago
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.
- matt_oriordan 5y ago
  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
  - deleted 5y ago
    [deleted]
  - mwcampbell 5y ago
    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 5y ago
      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!

lvass 5y ago

>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 5y ago
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 5y ago
  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!

nlitened 5y ago

> 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”