I use Socket.IO because using HTTP requests for a real-time multiplayer game just blows! Even with websockets, I had to scrunch the data being transmitted down to a bare minimum, and do some cheap compression tricks so that I can send data in JSON format. Otherwise, I would have to resort to sending binary data. I may end up doing that anyway when the time comes that I need to scale.

How do I use it? Each client opens a socket connection at startup. The server keeps track of these connections, and sends each client the visible portion of the Playfield repeatedly. The clients render this information, while sending requests and commands to the server (join,turn,fire,thrust,bomb,viewport change,etc.) in response to the player's actions. The server uses that to make adjustments to the player's ship on the Playfield.

We use it for a few things. We use it internally for a few dashboards because it’s actually really nice to have real-time dashboard data with Firebase. We also use it extensively for live order updating. For example, when a shopper is picking your items, you'll be able to go on your order screen. There will be live showing like found or not found or whatever. You'll have live position updating of your shopper on the map. You will have live information of the status of the order like “Nicole is now picking up your order,” and all these kind of things, so you don’t have to reload the page or pull or anything. Just live updates happen natively through Firebase API, which is nice.

We use it for a few things. We use it internally for a few dashboards because it’s actually really nice to have real-time dashboard data with Firebase. We also use it extensively for live order updating. For example, when a shopper is picking your items, you'll be able to go on your order screen. There will be live showing like found or not found or whatever. You'll have live position updating of your shopper on the map. You will have live information of the status of the order like “Nicole is now picking up your order,” and all these kind of things, so you don’t have to reload the page or pull or anything. Just live updates happen natively through Firebase API, which is nice.

Where we have browser support (recent Chrome, Firefox, and Safari), we make a WebSocket connection so that the server can push changes made by other people down to browsers listening on the appropriate channels. We use a modified version* of the Socket.io client and server libraries that allows us to keep many thousands of open WebSockets on each of our servers at very little cost in terms of CPU or memory usage. So when anything happens to a board you’re watching, that action is published to our server processes and propagated to your watching browser with very minimal latency, usually well under a second.

Used for storing results of users (malaria predictions) and displaying to user in the app. Although the realtime aspect wasn't huge in this project, it was much quicker to push data elements for each user as firebase elements since they were purely numerical and very small. And again, the idea of familiarity - I've worked with Firebase at previous hackathons, so no need to spend time going through docs, just straight to the coding.

Socket.IO has a decent community footprint, including integrations with popular JS frameworks, and has fallbacks to maintain an app's services if websockets are not available for some reason. Websockets are an important factor in most of the web-facing apps I build, to provide asynchronous two-way communication between the app and whatever server or data source it is connected to.

Firebase let's us iterate quickly. We've used the Realtime Database to build rich UX features– like push notifications– fast. Likewise, Firebase Authentication and Cloud Functions save us from having to rebuild redundant server infrastructure. Even though Firebase can get pricey, we've saved money in developer time.

Another one that we're not using, yet. But have realtime data updates within our applications and the central API will be a great bit of functionality that gives our clients more control and keep them informed of changes and updates in their stores, in real time.

Using websockets is something, scaling a message pipeline to thousands of concurrent connections is something else.

I trust PubNub with what it does best, and use it as zerotoherojs.com ’s messaging pipeline.

With PubNub, I have one less problem to think about.

Socket.io is used as our current multiplayer engine. The existing engine is very simplistic and only utilizes the websocket+http fallback transports and serves as a generic world/zone/screen grouping mechanism for displaying users to each other.

Still in development, but we will soon (January 2016) be releasing a version that uses Firebase to keep the front end up to date in real time. Certain data are synchronised across RDS and Firebase to optimize the user experience.

Flutter uses PubNub for sending push notifications when the users add new posts to the Flutter Community or leave comments.