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.

In the original prototype all the communication was handled by a backend server. Each client connected directly to the server using the socket.io library. This quickly proved to be messy and unreliable, especially on the cheap server being used to host it.

Websockets proved to be a little more reliable, but still just as messy and not all browsers support them. That's when the project was switched over to use Pusher. Using Pusher has allowed all but the initial connection code to be off-loaded onto the client. Now instead of communicating through a self-hosted server, clients can communicate pretty much peer-to-peer over Pusher.

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.

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.

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.

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.

Pusher is used to send update notification whenever Lapzbot joins a server.

Push real-time updates