The awesome simplicity that is Firebase

The awesome simplicity that is Firebase

Of all the Software-as-a-Service tools I’ve found popping up around the web in the past few years, Firebase is by far the one that has most changed how I look at the Internet, and to some degree software development in general. 

Firebase provides hosted, real-time databases that you edit and query via ReST calls (or using their spiffy WebSocket-enabled Javascript API). The data model is a straight up plain-old-JSON-object tree. Data access protection – both validation and authorization – is configured by a separate JSON object whose structure matches that of your own data model, but whose leafs are either validation or permissions ‘patterns’.  

Customer Driven Development

The simplicity behind their design is breathtaking, once it really hits you. It is quite obvious that the Firebase team has taken the approach of ‘justify every feature’. I’ve found no instance of ‘just in case’ development; features added because ‘I bet someone will want to…’. Each command and feature seems well thought out with respect to all the others, such that the result is a small, easily learned API, that is powerful enough to allow developers to do anything they would be able to do on even the most advanced relational database. Except the learning curve is days, not years.

Root, Tree and Branch

My favorite simplification has to be the treatment of ‘the web’ (or at least the part that is your Firebase DB) as an acyclic graph. A tree. Every URL (sans query) is a reference into the tree. No matter where along a branch you reference, what you get back consists of the entire child tree. From your reference down, including each and every leaf.  Query parameters operate on direct children, not descendants or relationships. It’s such a neat and tidy solution to the question of ‘what should I return for `GET /myApi/customers/` versus `GET /myApi/customers/cust-101`?‘. No more returning a list of references for the request to `customers` and then a full Customer object on the request to `cust-101`.  

Which isn’t to say you can’t return a list of references. Heck no! It’s hard to argue in favor of a single JSON object containing all of your customers. Having a single Document holding all of your fully defined customer instances would be horrible practice in any document store (MongoDB, Couch, etc). So why should your ReST API be structured to return it as such. Just define your `/customers/` endpoint to contain a list of customer ids, and define another endpoint `/customer/{id}`. Restrict direct access to `/customer` so that nobody can pull down the entire tree at once and you’re golden. Now the API you’ve created and the mental model are more similar, meaning less mental overhead wasted on silly stuff.

Instant Gratification

If you haven’t played with Firebase yet – perhaps because the name reminded you of Firebird or some other craziness – you should try it. Right now.  Seriously. The 5-minute tutorial they’ve set up is one form of instant gratification.  Another will come when you start playing with that real-time, Web Sockets based api in a real multi-user environment. All that crufty setup you used to have to do to kickstart a Java based web app – gone. Hours of tedious boilerplate replaced with a few clicks. The web development experience is truly starting to move out of the morass of backend wheel-reinvention and into a sweet, sweet plug-and-play world. I, for one, welcome our new… nevermind. Go check it out. You won’t regret it.