Thanks for the well-thought-out response, I appreciate it. Of course you're right that for some usecases, rolling your own infrastructure on Kubertetes or Swarm

Thanks for the well-thought-out response, I appreciate it. Of course you're right that for some usecases, rolling your own infrastructure on Kubertetes or Swarm with an open source solution rather than using a SAAS is the right way to go. (But then, the same thing is true of most SAAS products). BTW, I'd be interested to know if you had a particular open source product in mind in your first para? > For example, if your product requires that you have longer channel names, a more lightweight protocol, ability to batch messages together in a particular way, transform or filter or analyse data streams on the backend as they arrive, apply advanced authorization rules on the backend or to integrate directly with data from your own database... you need an open source solution. I'd query a few of these - - Re channel name length: we have no particular limit on that...? - Re lightweight protocols: The article we're commenting on is actually about us adding support for more protocols :) (including MQTT, which is pretty lightweight - though that one's not in general availability yet). We also support queues as an alternate way to consume data, which gives you AMQP and STOMP too. - Re batching: Clients can batch messages together into a single protocol messages as they like, just by passing an array of messages to publish(), and subscribers will receive them all together. (Which assumes they're all for the same channel, but if not, not sure what it'd mean to batch them). - Re analysing data streams on the backend as they arrive: you can subscribe to messages on your server, and then do what you like with them. (Or alternatively use our queueing feature, which lets you have arbitrarily many independent backend workers consuming messages from the queues). It is true that you can't filter messages before they're broadcast to other clients, though. I guess our answer to that would be to have the client publish to a channel that only the server has permissions to subscribe to, set then have server filter those and rebroadcast on a different channel. (Probably in combination with the queues, so you can have multiple server workers doing this). It's true that that will add a bit more latency, though. - Re advanced authorization rules -- our token capabilities system allows the server pretty fine-grained control over the permissions it grants each client.[0] But sure, it's never going to be as flexible as a completely custom solution. [0] https://www.ably.io/documentation/general/authentication https://www.ably.io/documentation/general/authentication