Both Pusher Channels and socket.io allow you to publish and subscribe to messages in realtime using the WebSocket protocol.
The main difference is that Channels is a hosted service/API, and with socket.io you need to manage the deployment yourself.
In general, you need to do less work to get started with Channels, and once it comes to scaling that really becomes a LOT less work :)
While that's true for Public channels (the simplest use-case) - the Channels API supports client events too - using either Private or Presence channels.
Alternatively you could create an API through which the clients would communicate, and the server would broadcast the events.
It really depends on your particular use-case, what kind of events will your clients be creating, and what makes the most sense for it.
Webhooks wouldn't for instance allow you to block client events, only observe them.
As the core concepts of subscriptions, channels, and events are quite similar, it should be a fairly quick migration - but of course it all depends on your concrete project and implementation.
Hey, I'm a developer evangelist at Pusher.
I don't see it as a better/worse kind of deal.
Both Pusher Channels and socket.io allow you to publish and subscribe to messages in realtime using the WebSocket protocol.
The main difference is that Channels is a hosted service/API, and with socket.io you need to manage the deployment yourself.
In general, you need to do less work to get started with Channels, and once it comes to scaling that really becomes a LOT less work :)
The use-cases of Channels are also a bit more narrow.
It seems to me that the main idea behind channels is, that you publish changes from the server to the client.
For example, I change a blog-post and people on dev.to get notified that there was an update to that post.
While socket.io lets you publish events from the clients, that go over your server logic to other clients.
While that's true for Public channels (the simplest use-case) - the Channels API supports client events too - using either Private or Presence channels.
pusher.com/docs/client_api_guide/c...
The tl;dr; version is:
But can I control the client events on my server somehow?
For example, if I want to create a game, I need pipe the client events through some server side logic.
You could do that using WebHooks, they allow you to capture all client events on the server - pusher.com/docs/webhooks#client_ev...
Alternatively you could create an API through which the clients would communicate, and the server would broadcast the events.
It really depends on your particular use-case, what kind of events will your clients be creating, and what makes the most sense for it.
Webhooks wouldn't for instance allow you to block client events, only observe them.
How easy would it be to move from socket.io to pusher and vice-versa?
As the core concepts of subscriptions, channels, and events are quite similar, it should be a fairly quick migration - but of course it all depends on your concrete project and implementation.
Is there a way to close user connections on the server?
I'll double check but I don't think so.
You could send a message to a particular user that you wish to disconnect and handle that clientside.
What is your use-case for this?
I want to use presence channels for games. When a game is finished, the users should be removed from the channel.
Ah yeah - just send a message that tells the clients to unsub from the channel, that should be the best way.
I've asked the team working on Channels and we don't support terminating connections from the server.
Well, guess for this contest it should be enough, thank you.