83

Jobs

0

Hacker News, Reddit, Stack Overflow Stats

GitHub Stats

Description

What is
Firebase?

Firebase is a cloud service designed to power real-time, collaborative applications. Simply add the Firebase library to your application to gain access to a shared data structure; any changes you make to that data are automatically synchronized with the Firebase cloud and with other clients within milliseconds.

What is
Socket.IO?

Socket.IO enables real-time bidirectional event-based communication. It works on every platform, browser or device, focusing equally on reliability and speed.

What is
Syncano?

Syncano is a backend platform to build powerful real-time apps more efficiently. Integrate with any API, minimize boilerplate code and control your data - all from one place.

Want advice about which of these to choose?Ask the StackShare community!

How developers use Firebase vs Socket.IO vs Syncano

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 made it really easy to do two things. 1) Store the shared code developers were sharing 2) Make it real-time simply by including some of their JS libraries. The reason I built CodeShare was to try out Firebase.

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.

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.

Firebase is included within our Android- and iOS-App so that we can react and monitor our mobile Applications in a flexible and dynamic fashion. This way we can react on occuring errors fast and reliable.

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.

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.

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.

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.

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.

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.