Need advice about which tool to choose?Ask the StackShare community!
Pusher vs Socket.IO: What are the differences?
Both Pusher and Socket.IO are popular real-time web application development frameworks that facilitate real-time communication between clients and servers. Let's discuss the key differences between them.
Scalability: Pusher is a cloud-based service that simplifies real-time communication by handling server infrastructure. It provides a highly scalable solution and takes care of scaling as the number of users and connected devices grow. On the other hand, Socket.IO is a library that enables real-time bidirectional event-based communication between clients and servers. It is not by default scalable and requires additional setup and configuration for managing scaling in a distributed environment.
Technology Stack: Pusher primarily uses WebSockets for real-time communication, providing a persistent connection between the client and server. It supports fallback mechanisms like HTTP long polling to ensure compatibility with older browsers. Socket.IO, on the other hand, supports various real-time communication techniques, including WebSockets, HTTP long polling, and server-sent events. This makes Socket.IO more flexible and compatible with a wider range of browsers and devices.
Ease of Use: Pusher offers a simple and straightforward API that abstracts much of the complexity involved in real-time communication. It provides client libraries for multiple programming languages, making it easier to integrate real-time capabilities into applications. Socket.IO also provides an easy-to-use API, but it requires more configuration and customization compared to Pusher, especially when it comes to handling specific use cases.
Community and Ecosystem: Pusher has a large and active developer community and a mature ecosystem. It offers extensive documentation, tutorials, and community support, making it easy for developers to find resources and solutions to common problems. Socket.IO also has a thriving community and a broad ecosystem, but it may not have the same level of maturity and resources as Pusher.
Hosting and Infrastructure: Pusher is a cloud-hosted service, which means that the infrastructure and server-side components are managed by Pusher themselves. This reduces the burden of managing servers and infrastructure for real-time communication. Socket.IO, being a library, requires developers to set up and manage their own servers and infrastructure, which can be advantageous for developers who prefer more control over their system.
Cost: Pusher offers a range of pricing plans, including a free plan for limited usage. Their paid plans scale based on the number of concurrent connections and features required. Socket.IO, being an open-source library, is free to use and can be hosted on any server infrastructure. However, hosting and managing the infrastructure for Socket.IO may incur additional costs.
In summary, Pusher provides a scalable and user-friendly real-time communication service with a cloud-based infrastructure, while Socket.IO is a flexible library that requires more configuration and customization. Pusher has a larger community and ecosystem, but Socket.IO is free to use and offers more control over hosting and infrastructure.
We (my team) are building an App where we want to have Bi-directional texting, Single Directional Picture, and audio transfer.
We are building all this using Flutter.
There will essentially be 3 apps, 2 Mobile-based (Android and iOS) and 1 Microsoft Based. We've built up most of the code already, and made a few major mistakes but fixed it(namely had no proper state management).
How things will work:
Person A has a Mobile app 1, Person A presses a button that sends a "communication request" into a Pool of requests. Person B on Desktop App chooses a "communication request" from the pool, and engages in Bi-directional texting with Person A. Person B also opens communication with Person C who is on Mobile app 2, and they engage in Bi-directional texting. Person C will be notified of communication requests through Push Notifications.
So far we've been using Socket.IO, however, I'm starting to think that's not the best.
A problem we've encountered so far is that Person A(Mobile App 1 User), is the person who sends a "communication request" into the "Communication Pool". The Mobile App 1 User, can "cancel" the communication at any point in time. When they do that, I would like for a notification to be sent to Person B, the Desktop User, For them to pick up another communication request.
I am not sure how this should be done however, should it be done in the Back-end, then how does the Front-end get notified of the change?
Any advice on which to choose?
It's so simple when you use Firebase to manage the requests just make new field to the request for example callstate with values like "requesting" "incall" "cancelled" and both A and B can update this field.
I am building an IoT application that will utilize connected air quality sensors to provide real-time indoor air quality in offices. I want to be able to share this data with a few different databases, etc.
Wondering if anyone has any advice on which real-time streaming API would be best for this sort of application, or even how I should think about it?
For IoT, we support MQTT along with websockets and SSE. The pattern you're suggesting that involves harvesting data from devices and soaking into a database is easy to achieve with one of the Ably integrations (Serverless functions/webhook) . Here are some tutorials to do things like this: https://ably.com/tutorials/reactor-event-zapier#step2-mqtt-ably
We use Pusher at www.justlearn.com. It works fine. When you reach more users, Pusher gets expensive. We use Pusher for live chat between users. Their software is easy to use. We have had issues with auth on Pusher.
We are starting to work on a web-based platform aiming to connect artists (clients) and professional freelancers (service providers). In-app, timeline-based, real-time communication between users (& storing it), file transfers, and push notifications are essential core features. We are considering using Node.js, ExpressJS, React, MongoDB stack with Socket.IO & Apollo, or maybe using Real-Time Database and functionalities of Firebase.
I would recommend looking hard into Firebase for this project, especially if you do not have dedicated full-stack or backend members on your team.
The real time database, as you mentioned, is a great option, but I would also look into Firestore. Similar to RTDB, it adds more functions and some cool methods as well. Also, another great thing about Firebase is you have easy access to storage and dead simple auth as well.
Node.js Express MongoDB Socket.IO and Apollo are great technologies as well, and may be the better option if you do not wish to cede as much control to third parties in your application.
Overall, I say if you wish to focus more time developing your React application instead of other parts of your stack, Firebase is a great way to do that.
Hello Noam 👋,
I suggest taking a look at Ably, it has all the realtime features you need and the platform is designed to guarantee critical functionality at scale.
Here is an in depth comparison between Ably and Firebase
Hey Noam,
I would recommend you to take a look into 8base. It has features you've requested, also relation database and GraphQL API which will help you to develop rapidly.
Thanks, Ilya