After building out the frontend for, I was in need of a backend. I recently heard about Firebase, and figured it would be a perfect fit for this project. Check out a quick video overview and my rundown below:

Up And Running

I was blown away at how quickly I could get up and running with Firebase. With two lines of Javascript, I was persisting data to a server. I can’t find the words to describe how awesome this felt.

var ref = new Firebase("<endpoint>");
ref.set({hello: 'world'});

De-normalizing my Data

Most of my experience is with relational databases, not MongoDB style document stores or “NoSQL” databases. Because of that, my initial reaction is to see denormalized schemas as “wrong”. It took a good amount of time to convince myself that mirroring my data in two separate collections was the right way to go about things.

I played with the idea of somehow using Firebase priorities to get around this, but in the end I realized I couldn’t lookup data by URL and key without two separate collections. This is definitely just a mental shift that I need to get over when working with this style of database.


One of the coolest things I found while playing with Firebase was the use of WebSockets to push events down to the client. I can see this being a huge deal when combined with something like AngularJS (AngularFire). Three way binding from the DOM all the way up to the database? Yes please!

I’ve been imagining something like a CQRS style system where commands are implemented as explicit calls (maybe even traditional REST PUT/POST/DELETE requests?) to the server, but all of the querying is done using Firebase style WebSocket endpoints that can automatically listen for data changes. I’m still fleshing these ideas out, but I’ll definitely be thinking more about this kind of thing in the future.


So that’s it! is finished and live. Watch out bitly, there’s a new sheriff in town!

Check out the project on github!