Firebase vs WebSocket: Differences and how they work together

WebSocket is a realtime protocol that provides a persistent, bi directional communication channel between a web client (e.g., a browser) and a web server over a single TCP connection.

A WebSocket connection starts as an HTTP request/response handshake between the client and the server. The client always initiates the handshake; it sends a GET request to the server, indicating that it wants to upgrade the connection from HTTP to WebSockets. The server must return an HTTP 101 Switching Protocols response code for the WebSocket connection to be established.

Once the connection upgrade is successful and switches from HTTP to WebSocket, the client and server can freely exchange low-latency messages over the connection as and when needed. After the WebSocket connection has served its purpose, it can be terminated via a closing handshake (both the client and server can initiate it). 

The standardized WebSocket API, which is supported by the vast majority of browsers, extends the WebSocket protocol to web clients. The WebSocket API allows you to perform actions like creating the WebSocket object, managing the WebSocket connection, sending and receiving messages, and listening for events triggered by the WebSocket server. 

Learn more about WebSockets:

• How WebSockets work

• The challenge of scaling WebSockets

• Scaling live experiences: Horizontal vs vertical scaling for WebSockets

• Minimal transmission overhead. Unlike earlier HTTP-based approaches (such as HTTP long polling), the WebSocket protocol uses persistent connections rather than a continuous request/response cycle. When it comes to realtime communication, WebSockets require less bandwidth and provide lower latency compared to HTTP, while significantly reducing the load on the server side.

• Flexibility is ingrained into the design of the WebSocket technology, which allows for the implementation of application-level protocols and extensions for additional functionality (such as pub/sub messaging).

• WebSocket is a mature and widely adopted technology: most programming languages support Web Sockets, and there are numerous libraries, frameworks, and platforms using the WebSocket protocol (including Firebase). Additionally, almost all modern browsers natively support the WebSocket API.

• The WebSocket protocol is stateful. This can be tricky to handle, especially at scale, because it requires the server layer to keep track of each individual WebSocket connection and maintain state information.

• WebSockets don’t automatically recover when connections are terminated – this is something you need to implement yourself, and is part of the reason why there are many WebSocket client-side libraries in existence.

• Even though WebSockets generally benefit from widespread support, certain environments (such as corporate networks with proxy servers) will block WebSocket connections.

Firebase is a Backend as a Service (BaaS) platform that helps you build, test, release, and monitor web and mobile apps for end-users. While it initially started as a realtime database, Firebase now provides a host of services and features. Here’s a non-exhaustive list:

• Realtime database. At its core, Firebase is a cloud service that allows you to store data related to your application and service. Firebase offers two different non-relational database options: the Firebase Realtime Database, and Cloud Firestore, the newer database for mobile app development, providing a more intuitive data model and enhanced capabilities for querying data.

• Cloud and in-app messaging. Both Firebase Realtime Database and Cloud Firestore can push realtime updates to client devices following any changes to the database. There’s also Firebase Cloud Messaging, a service that allows you to send native push notifications and notification messages across platforms (iOS, Android, web). 

• Hosting. Firebase provides secure hosting on Google Cloud.  

• Integrations. Given that Firebase is powered by Google, this naturally extends its functionality via integrations with services such as Google Pub/Sub, Google Cloud Functions, and Google Analytics.

• App analytics. Firebase comes with a nice dashboard for visualizing your app’s activity, so you can make critical business decisions based on this data.

We’ll now cover some of Firebase’s key advantages and disadvantages (note that this is a non-exhaustive list). 

• Firebase helps app developers move quickly: you don’t have to worry about hosting, provisioning, and managing backend processes and components like databases, data storage, and authentication. Firebase’s collection of services makes the entire development cycle shorter and more straightforward. 

• Firebase has good technical documentation, and detailed SDK and API reference, making it easy to get started and use the platform. Going beyond docs, there are about 1.5 million apps built with Firebase, so there’s a pretty big community of experts who can help you with questions and issues. 

• Most of the Firebase services are free to start with, which is great if you are new to Firebase and simply want to test the platform, assessing if it’s the right choice for your project.  

• An instance of the Firebase Realtime Database has a limit of 200.000 concurrent connections and 1.000 write operations per second. To scale beyond these limits, you have to use sharding, which is a notoriously difficult process. 

• Vendor lock-in is an issue when you use Firebase. For example, if one day you conclude that the Realtime Database / Cloud Firestore is unsuitable for your use case, it’s hard to migrate to another (NoSQL) database. This is because of the way data is stored - a JSON tree in the case of the Realtime Database, respectively collections of documents (which are very similar to JSON data) in the case of Cloud Firestore. 

• There are plenty of horror stories of costs escalating out of control, especially if you are new to Firebase, and don’t yet have a good grasp on the pricing mode and how to engineer your apps in a cost-effective manner. See How not to get a $30k bill from Firebase for details.

We’ll now briefly cover the kind of realtime features you can build with WebSocket and Firebase. 

We can broadly group WebSocket use cases into two distinct categories:

• Realtime updates, where the communication is unidirectional, and the server is streaming low-latency (and often frequent) updates to the client. Think of live score updates, GPS location tracking, live dashboards, or realtime alerts and notifications, to name just a few use cases.

• Bidirectional communication, where both the client and the server send and receive messages. Examples include chat, multiplayer gaming, virtual events, and virtual classrooms (the last two usually involve features like live polls, quizzes, and Q&As). WebSockets can also be used to underpin multi-user synchronized collaborative applications - think of Figma.

Both the Firebase Realtime Database and Cloud Firestore can push updates in realtime to connected clients every time data changes. This is especially useful for use cases like chat and live multiplayer games. In addition to the two databases, there’s Firebase Cloud Messaging (FCM), a cross-platform messaging solution that enables you to send realtime messages and notifications across platforms (iOS, Android, Unity).

As mentioned earlier in the article, Firebase provides two different NoSQL databases: the Firebase Realtime Database, and the more recent Cloud Firestore. Data stored can be synchronized across all clients in realtime, with low latencies - every time there is a change in the DB, connected devices will receive an update. Note that Firebase uses WebSockets for data synchronization with clients.

There are several limitations to the way Firebase databases use WebSockets. First of all, the database is the central concept, with realtime synchronization (messaging) as an add-on feature. Only the updates to your database are published to connected clients. This forces you to permanently store even the transient events that need to be streamed to your users, leading to an unnecessary increase in storage costs. An example of transient messages in a chat app scenario would be indicators that others are typing – events that occur frequently but have zero need for permanent storage.

Another downside of this tight coupling of database + realtime messaging is that it leaves no room for flexibility. For example, you can’t use Firebase to push updates to client devices from a non-Firebase database. One could argue that coupling a realtime messaging service and a core database is peculiar, because the two vary in semantics and levels of scalability. 

Speaking of scalability, you can scale the Firebase databases up to a point. We’ve previously mentioned that an instance of the Firebase Realtime Database has a limit of 200.000 concurrent WebSocket connections. You can scale beyond this limit by sharding your data across multiple instances. However, it’s worth bearing in mind that sharding can become a significant challenge that leads to increased complexity and management overhead. 

Rather than having to deal with sharding, you’re probably better off using Cloud Firestore, which auto-scales up to a more generous limit: roughly 1 million concurrent connections. However, if you need to scale beyond 1 million users, Cloud Firestore can’t help you. In addition, unlike the Realtime Database, Cloud Firestore does not support presence natively, which is a key feature for use cases like chat apps. 

In the previous section, we’ve seen the downside of using the Firebase databases for synchronizing updates to client devices. With that in mind, it might be worth exploring specialized solutions for last-mile, WebSocket-based realtime messaging that you can connect to your Firebase backend, as opposed to using Firebase native capabilities for synchronizing data to client devices.

With a realtime messaging solution between Firebase and client devices, you can stream transient messages directly to clients, and only send messages that require permanent storage to the DB. This helps reduce the load on the database and prevents increased costs for storing data that you don’t want to store to begin with.

Ably provides realtime experience infrastructure to power multiplayer, chat, data synchronization, and notifications at internet scale. Our globally-distributed network and hosted APIs (WebSocket-based) help developers engineer realtime features for millions of users. Ably often acts as a last-mile middleware for synchronization between client devices and various backend solutions (including Firebase).