I saw a presentation on Firebase recently by David East, and as a result, my mind is still blown (and yours should be too). Wait…is it true that this service can eliminate the need for the server side of your application? And is it also true that you don’t even need a database anymore, even if you have simultaneous multi-client transactions you need to process? Seriously, does this mean I don’t need to make an HTTP request to my server to authenticate my users, return live data from my DB, and write back to my server when data changes?
The answer to all of these is an astounding YES! but, but, but….how?
Real-time data is the key here. Back in the day, when I was building iPhone apps, I realized how hard it was to make a live multiplayer video game. Aside from building the front-end (in this case, using Objective-C), you would need a server which your clients (users playing on your application) could all sync their data to, and retrieve data from. My idea was to create a server which people could just easily send messages to and from in a simple way, like using AJAX calls or other types of asynchronous requests. Of course, Firebase has provided all of the means to do this exceptionally well, and developers all over the world are going to be very glad they did.
With Firebase, you can now build an application which retrieves and stores data via a public REST API, using JSON. Under the hood, Firebase uses a NoSQL database to store and retrieve data in real-time. The real-time data is synced across clients retrieving it, so in some ways this is actually superior to most back-end solutions: Sure, you can use WebSockets to minimize connections from clients, but the messages going back and forth between client and server could still be out-of-sync; on the other hand, Firebase can provide all clients the same exact view of the the server state. I guess it makes sense that this service evolved out of a chat client with similar requirements.
Firebase also supports authentication (via Simple Login), and security (via Security Rules). With this you pretty much have everything you need to start building server-less web applications. Your users don’t care if you have your own server or database, all they care about is the resulting front-end experience. Being a devoted Backbone engineer, I’m happy to say that Firebase’s Backfire library provides custom collections which seamlessly integrate with the Firebase API. In the demonstration by David East, he quickly put together a backbone app, and deployed it to Firebase’s hosting services (which use certs), right from the command line. Once deployed, this application was live to the masses, and he could inspect all of the application’s data in easy-to-read foldable structures using Vulcan, a chrome plugin which inspects Firebase data. It’s so easy!
Now does this mean everyone needs to drop their servers and DBs and switch to Firebase? Can you replace the back-ends of popular sites like Twitter, Uber, Google Docs, or Facebook? Well…maybe…or maybe not. You see, data from a back-end server isn’t always just retrieved or propagated, it’s processed. Data needs to be aggregated, formatted, compared, curated, etc…In the normal development world, this still requires back-end server code and a database. I mean c’mon, can you really do this without SQL queries? Firebase is currently working on ways to help these common data processing needs with things like priorities (which let you set the weight of certain data requests), formatting methods (such as limiting the data with pagination), and transactions (which help you with data race conditions). But obviously there’s still a long way to go before application-specific back-ends are a thing of the past. Still, Firebase offers a path in the right direction, and I guarantee that it (or a similar service) will change the face of web application development across the internet. I can’t wait to use it myself :)