4 ms·

How is this different from Signal R? Signal R provides Real-time Duplex communication. It's dead-simple to use and it's FREE. https://github.com/SignalR/SignalR

How is this different from Signal R? Signal R provides Real-time Duplex communication. It's dead-simple to use and it's FREE. https://github.com/SignalR/SignalR https://github.com/SignalR/SignalR I looked at ably.io's features / platform page https://www.ably.io/platform https://www.ably.io/platform and don't see anything that Signal R can't do. Can someone from ably.io convince me as to why I should be shelling out 500$ a month (as an enterprise client) to use ably.io? The only reason I see is an existing technology stack that can't allow or handle Signal R (.Net) and that's a weak argument.

jkarneges 10y ago
Apples and oranges. Ably is a cloud service. It costs money, but so does SignalR if you factor in having to run your own servers (and not just the servers themselves but also the ongoing operational labor. $500 is nothing in that context). I say this as an operator of a competing cloud service, defending the product category. ;)
- matt_oriordan 10y ago
  Thanks Justin, I obviously concur!
- jondubois 10y ago
  I never understood the need for pub/sub as-a-service. Running your own pub/sub service is easy - As easy as running an HTTP service - Scaling out is also almost as easy as scaling an HTTP service. Yet no company is offering HTTP-as-a-service; that would be silly. I think that the whole industry exists because of a myth spread by PR and marketing. We'll see in a few years. I think people will come to their senses eventually.
  - SEMW 10y ago
    > Running your own pub/sub service is easy Yep, creating a barebones pub/sub service is pretty trivial (and fun!). But then you may find yourself slowly adding things that a decent pub/sub service should have. E.g. connection state recovery, so that a client on a phone driving through a tunnel gets all their messages (in the right order) once they reconnect. Presence, and presence data. Stored history. A permissions system. Encryption. Smart push notifications. Decent multi-region federation, so a channel that happens to only have subscribers in ap-southeast doesn't roundtrip messages to us-east. Guaranteed message ordering preservation. And so on. And eventually, you end up spending what adds up to quite a lot of effort, which could have been spent in ways other than slowly recreating the SAAS. I think that's the case for a lot of SAAS products (that creating a barebones version of the product yourself is pretty trivial, but the SAAS is still a useful product, since often people don't just want a barebones version). (Disclaimer: I work at Ably)
    - jondubois 10y ago
      There are a quite a few open source pub/sub solutions which handle connection state recovery, authentication, encryption, in-order-and-exactly-once delivery, auto-scalability (on Kubertetes or Swarm)... And they give you even more flexibility than what you can get from a third-party service (which give you limited or no ability to customize back-end logic). There might be a few minor features which the third-party service might have which the open source solution doesn't have; but you can always extend the open source solution to have those features; this not the case with the third-party service; in that case you're stuck with whatever features are being offered by the service... 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 would say that the argument for using third-party pub/sub services is the opposite of the one you made; it's good for simple projects which have limited requirements, but not good for larger companies with more advanced requirements.
      - SEMW 10y ago
        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
matt_oriordan 10y ago
Hey Sean, Matt here, co-founder of Ably. I have been meaning to write a blog post on this in fact, like I did some time back for ActionCable, see https://blog.ably.io/rails-5-actioncable-the-good-and-bad-parts-1b56c3b31404 https://blog.ably.io/rails-5-actioncable-the-good-and-bad-pa.... I've not done an in-depth review yet, but from what I can tell SignalR has the following shortfalls: - It relies on a single message bus for message passing between nodes. If your rate of messages exceeds what the bus can handle, you're in trouble. - I don't believe it handles connection state recovery as a service, and certainly does not do that across moving connections i.e. a disconnected client may arrive an another server yet messages may have been published whilst disconnected. - SignalR does not support multi-regions, once again due to the central bus, so if you have users in Asia and your datacenter in US, they'll all have to route everything through US. To be quite honest though, we're now rarely having discussions about technology X versus Ably, because Ably is realtime platform-as-a-service, and not a software solution. To provide the scale, reach, resilience and feature set we have, it can only be achieved with a combination of infrastructure and software. So our customers are choosing us because we're investing a lot of time and effort in all aspects of the service, not just the realtime software itself. See https://blog.ably.io/routing-around-single-point-of-failure-dns-issues-7c20a8757903#.oqciqec1t https://blog.ably.io/routing-around-single-point-of-failure-... for details on how the Dyn attack did not affect us for example, or https://blog.ably.io/the-18-ghosts-in-your-infrastructure-stack-that-can-cause-failure-and-how-to-avoid-them-1373daebfe1a#.b7ya3o94o https://blog.ably.io/the-18-ghosts-in-your-infrastructure-st... for some details on we've built necessary resilience into every aspect of the system. I plan on doing an in-depth SignalR review soon in fact, thanks for the prod.
- sean_patel 10y ago
  Thank you Matt! I see your value proposition now. MaaS as a SaaS (i.e. Messaging as a Service as a Software as a Service) :) I still think that the strongest use case would be for large enterprises ( think Uber) that would be spread across geographical locations and would need something like this - reliable, with state saved and spread across data-centers. For the rest of us (think young startups, smaller shops) your costs may be prohibitive ( almost 6K / year).
SEMW 10y ago
> 500$ a month (as an enterprise client) (I work at Ably) Others have already replied to the main question, but just on this - the enterprise package is only if you want the features that come with that package, it's not like we try and detect what kind of business you are and charge you extra based on that. Free tier gives you 3 million messages/month, and above that we've transparent, usage-based pricing - https://www.ably.io/pricing/self-service https://www.ably.io/pricing/self-service

jkarneges 10y ago

Apples and oranges. Ably is a cloud service. It costs money, but so does SignalR if you factor in having to run your own servers (and not just the servers themselves but also the ongoing operational labor. $500 is nothing in that context). I say this as an operator of a competing cloud service, defending the product category. ;)

matt_oriordan 10y ago
Thanks Justin, I obviously concur!
jondubois 10y ago
I never understood the need for pub/sub as-a-service. Running your own pub/sub service is easy - As easy as running an HTTP service - Scaling out is also almost as easy as scaling an HTTP service. Yet no company is offering HTTP-as-a-service; that would be silly. I think that the whole industry exists because of a myth spread by PR and marketing. We'll see in a few years. I think people will come to their senses eventually.
- SEMW 10y ago
  > Running your own pub/sub service is easy Yep, creating a barebones pub/sub service is pretty trivial (and fun!). But then you may find yourself slowly adding things that a decent pub/sub service should have. E.g. connection state recovery, so that a client on a phone driving through a tunnel gets all their messages (in the right order) once they reconnect. Presence, and presence data. Stored history. A permissions system. Encryption. Smart push notifications. Decent multi-region federation, so a channel that happens to only have subscribers in ap-southeast doesn't roundtrip messages to us-east. Guaranteed message ordering preservation. And so on. And eventually, you end up spending what adds up to quite a lot of effort, which could have been spent in ways other than slowly recreating the SAAS. I think that's the case for a lot of SAAS products (that creating a barebones version of the product yourself is pretty trivial, but the SAAS is still a useful product, since often people don't just want a barebones version). (Disclaimer: I work at Ably)
  - jondubois 10y ago
    There are a quite a few open source pub/sub solutions which handle connection state recovery, authentication, encryption, in-order-and-exactly-once delivery, auto-scalability (on Kubertetes or Swarm)... And they give you even more flexibility than what you can get from a third-party service (which give you limited or no ability to customize back-end logic). There might be a few minor features which the third-party service might have which the open source solution doesn't have; but you can always extend the open source solution to have those features; this not the case with the third-party service; in that case you're stuck with whatever features are being offered by the service... 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 would say that the argument for using third-party pub/sub services is the opposite of the one you made; it's good for simple projects which have limited requirements, but not good for larger companies with more advanced requirements.
    - SEMW 10y ago
      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

matt_oriordan 10y ago

Hey Sean, Matt here, co-founder of Ably. I have been meaning to write a blog post on this in fact, like I did some time back for ActionCable, see https://blog.ably.io/rails-5-actioncable-the-good-and-bad-parts-1b56c3b31404 https://blog.ably.io/rails-5-actioncable-the-good-and-bad-pa.... I've not done an in-depth review yet, but from what I can tell SignalR has the following shortfalls: - It relies on a single message bus for message passing between nodes. If your rate of messages exceeds what the bus can handle, you're in trouble. - I don't believe it handles connection state recovery as a service, and certainly does not do that across moving connections i.e. a disconnected client may arrive an another server yet messages may have been published whilst disconnected. - SignalR does not support multi-regions, once again due to the central bus, so if you have users in Asia and your datacenter in US, they'll all have to route everything through US. To be quite honest though, we're now rarely having discussions about technology X versus Ably, because Ably is realtime platform-as-a-service, and not a software solution. To provide the scale, reach, resilience and feature set we have, it can only be achieved with a combination of infrastructure and software. So our customers are choosing us because we're investing a lot of time and effort in all aspects of the service, not just the realtime software itself. See https://blog.ably.io/routing-around-single-point-of-failure-dns-issues-7c20a8757903#.oqciqec1t https://blog.ably.io/routing-around-single-point-of-failure-... for details on how the Dyn attack did not affect us for example, or https://blog.ably.io/the-18-ghosts-in-your-infrastructure-stack-that-can-cause-failure-and-how-to-avoid-them-1373daebfe1a#.b7ya3o94o https://blog.ably.io/the-18-ghosts-in-your-infrastructure-st... for some details on we've built necessary resilience into every aspect of the system. I plan on doing an in-depth SignalR review soon in fact, thanks for the prod.

sean_patel 10y ago
Thank you Matt! I see your value proposition now. MaaS as a SaaS (i.e. Messaging as a Service as a Software as a Service) :) I still think that the strongest use case would be for large enterprises ( think Uber) that would be spread across geographical locations and would need something like this - reliable, with state saved and spread across data-centers. For the rest of us (think young startups, smaller shops) your costs may be prohibitive ( almost 6K / year).

SEMW 10y ago

> 500$ a month (as an enterprise client) (I work at Ably) Others have already replied to the main question, but just on this - the enterprise package is only if you want the features that come with that package, it's not like we try and detect what kind of business you are and charge you extra based on that. Free tier gives you 3 million messages/month, and above that we've transparent, usage-based pricing - https://www.ably.io/pricing/self-service https://www.ably.io/pricing/self-service