Aug 5, 2016
Firebase is a backend-as-a-service that makes it remarkably easy to add real time, responsive features to an application without requiring developers to write a lot of complicated and error-prone code. Launching in 2012, it was acquired by Google in 2014 and incorporated into their cloud development platform.
In this article I want to describe the various reasons why Firebase is a great platform for building real-time collaborative apps, as well as help you to decide whether it is the right choice for you, whether you are planning to build something from scratch, or add a new feature to an existing application.
Internet apps are now multi-user and collaborative
Web pages have come a long way since the 1990s, when the Web was a sea of static content peppered with the occasional HTML form. As browsers and standards evolved in the days of Web 2.0 in the early 2000s, developers began to build more responsive features into web apps. Web pages became mutable, allowing users to modify content and feed their changes back to the server without needing to click a Submit button and wait for the page to refresh. Web pages could also update themselves dynamically in response to the click of a button or drag of a mouse. In short, web apps began to acquire the features of desktop apps.
Now the movement of desktop-class applications online, in combination with the suite of features in HTML5, has given rise to a completely new class of application. In these new applications, we see rich functionality combine with multi-user interaction, allowing people to collaborate in the same virtual workspace and share ideas in real time. Examples with which many of us would be familiar are the chat features embedded into platforms like Facebook, or Slack, which are slowly taking the place of email. In the productivity space, Google Docs and Microsoft Office Online add collaboration features to traditional office software. A more niche product such as Trello allows groups of people to share and comment on Kanban-style boards; creating and rearranging lists of notes and sharing their changes instantaneously.
Real-time interactivity is Firebase’s killer app, allowing you to leverage its features to build multi-user collaboration into your own products.
Your database as a big, cloud-hosted, JSON tree
Firebase’s real time database falls into the NoSQL category. NoSQL is a catch-all term for database platforms other than traditional relational databases such as Oracle, MySQL and SQL Server. While there is no substitute for relational databases in terms of familiarity and reliability, there are many problem domains for which a relational database might not be the best choice. A search engine, for example, might use a NoSQL database designed specifically to provide fast, relevant search results, rather than a SQL database for which full-text search is a secondary concern.
The structure of a Firebase database could be described as a tree of nodes, where the entire database branches out from one root node. Any location in a Firebase database can be expressed as a path from this root node. Additionally, an entire Firebase database can be expressed as a JSON document. JSON is a standard for expressing hierarchical data structures which has the advantage of being a subset of JavaScript, a programming language embedded into web browsers.
Because Firebase is a back-end-as-a-service, your entire database is hosted in the cloud. While this means that you have less control over your hosting environment than you might otherwise have, you no longer face having to make large up-front investments in infrastructure. This means that new projects can be initiated more cheaply. Over time, you will also save on maintenance, allowing you to focus on developing new functionality rather than maintaining servers.
A pub-sub approach to data storage and retrieval
The traditional way of working with a relational database that most application developers are familiar with is best summarised by the CRUD acronym, standing for Create, Read, Update and Delete. Firebase’s approach, by contrast, is more of a publish-subscribe model (often shortened to “pub-sub”).
While writing to the database (or creating, updating and deleting) is roughly equivalent in both the CRUD and pub-sub approaches, reading data involves something of a paradigm shift. In a traditional application, it is the responsibility of the application code to poll the database whenever it wants to find out if something has been updated. For example, when a web page or refreshes itself, the web server will initiate the call to the database to find out what content to display. If the data changes, your application will not know about this until it initiates another call to re-read the data.
Firebase’s pub-sub approach turns this on its head. Instead of asking to read data from Firebase, you tell it that you want to subscribe to events, giving it the address of the node in the database that you’re interested in. When you do this, you’re effectively saying to Firebase: “notify me whenever there’s a change to this data node or anything below it, and keep on informing me of changes until I tell you to stop”. Whenever a change is published to this node, all of its subscribers are immediately informed.
This is the inverse to the traditional approach because it now becomes the responsibility of the database to inform the application when something changes. It is this attribute that makes Firebase a real-time database.
APIs for multiple platforms
Users have become accustomed to the idea that they can access an application from the device or platform that suits their needs, whether it be a desktop application, a web browser, a tablet or a smartphone. But supporting all of these platforms requires you to build and maintain multiple codebases. Firebase helps to reduce the multi-platform overhead by providing SDKs for web projects, iOS, Android, as well as libraries for C++, NodeJS and Java.
Out-of-the box support for common features
There are a number of “horizontal” requirements that are common to many apps; they are not unique to your app, but have to be provided nonetheless. Here are some of these features that Firebase provides out-of-the-box.
- Authentication: You can delegate authentication to a range of popular third-party providers, such as Google Accounts, Facebook and Twitter.
- Hosting: Firebase provides hosting for static web content. So if you are able to build your web app such that all of your dynamic web content runs on the client rather than a web server, you can use Firebase to host it.
- Analytics: Firebase provides a sophisticated analytics package to track and aggregate information about your users’ behaviour.
- Cloud messaging: Firebase provides a cross-platform solution to notifications; allowing you to implement notifications that can be delivered to your clients regardless of whether they are on iOS, Android or the web.
- Advertising: Google provides the ability to monetise your mobile applications through its AdMob platform.
Easy to get started and build a prototype
Google is trying hard to push Firebase as an app development platform and makes it very easy to get started. Anyone with a Google account can test drive Firebase by going to the developer console and creating a new project. Each project has its own database which can be inspected and modified via the console user interface. And, of course, updates to the database are reflected in the console in real time.
Hopefully this short run-down on Firebase’s features has given you an idea of the value that it can provide. As a genuinely unique offering amongst the various backend-as-a-service products, I believe that it seriously worth considering for anyone looking to add collaborative features to their application with as little overhead as possible.
