Again, I’m going to compare two very dissimilar things — Redis, the in-memory NoSQL powerhouse to Firebase, the real-time, front-end-centric key-value store. They are very different, but they are also fairly similar and have some similar programming challenges. Each has a distinct advantage in certain situations too (and there is no reason that you couldn’t use both in a project).
I’m going to assume that you know a bit about Redis and what it does. It’s fairly well known and there is lots written about it. I’m going to point out the places where Redis and Firebase really diverge. The first divergence is not related to a specific operation or syntax but rather delivery. Redis is an free, open-sourced product that you can run on your own server or go to any number of vendors to get a managed instance. Firebase is a vendor product. It’s closed-source, single-provider (although I think it is based on LevelDB and a few other open projects internally, but you can’t just go and stand up your own Firebase server). Firebase has been owned by Google (Alphabet now?) for about a year. This divergence is important and not to be taken lightly- Google could decided that the Firebase developers are needed elsewhere and :poof: you’re dead in the water. Firebase has said that it isn’t going anywhere but it’s always good to have the worse-case scenario in the back of your mind. You’re also locked into a pricing structure you can’t control and for which no competition exists (more on that later). Redis, being open sourced, on the other hand, will likely be HSETing and ZINTERSTOREing for decades to come with both vendor and community support.
The other important divergence between Redis and Firebase are the target developers. I’ve always seem myself as a balanced web app developer. I feel equally comfortable in both front-end and back-end work. While Firebase works on both the client-side and the server-side, it is definitely targeted at the front-end/client-side developer. Because of this bias, there are layers of managed code that provide the traditional server-side functionality needed for app development: authentication, access control, data validation and even password resets. That is a blessing and a curse — you can get up-and-running extremely quickly, but you’re locked into this formula- if your client wants to provide an unsupported authentication method, for example, you’re going to have a lot of code to write from scratch. It’s fairly nice to be able to provide significant functionality to an application by only serving static HTML files.
Finally, let’s get real. Realtime, that is. Firebase bills itself as a realtime database. I’m not sure if it is actually something I’d call realtime, but would say it is an event-driven database. In Firebase, you’re primarily building event responders that react to changing data at a specific key/value in a tree. So, all data in Firebase descends from a root key and you can watch for changes on that key or a child. The events bubble up — so if you change one value buried deep in the tree, all parents will also be marked as changed.
This happens seamlessly on all clients. It’s actually pretty neat: the Forge, which is Firebase’s built in data visualization tree shows a colour-coded response to the data as it is altered. I’ll admit I’ve wasted a fair bit of time on my recent Firebase project just sitting watching six devices and / or laptops in a circle around me all change state at once with very little latency. From a Redis perspective, this is pub / sub keyspace notifications— the differences being that Firebase is aware of key parent / child key relationships and it has added a layer of client-side friendly code.
Firebase has a much more simple data storage paradigm — it’s key-value with keys having parent-child relationships. Unlike Redis where you have Lists, ZSets, Sets, Hashes, Strings, and even HyperLogLogs, with Firebase, not even native sets exist. Firebase fudges some of these data structures by allowing for on-the-fly unique time-based-key generation with a push function, it’s still a key-value relationship though. They also have psuedo-zset like ability with an assignable priority number, but usage is a bit limited to what you can do besides ordering.
Don’t assume that every value in Firebase is a string. Firebase distinguishes between a boolean, string and a number as well as an object. In the case of an Object (pretty much a Redis Hash), it will create child elements based on the properties and values of the object. I had some hair pulling when I realized that some times I was saving “true” instead of true to Firebase, but it is a minimal leap to get over.
Since Firebase has baked-in auth, it also has a baked in security model. This takes some getting used to but is fairly powerful. The process essentially allows Javascript-based statements to evaluate synchronously over the data having access to a limited number of variables (user key, timestamp, etc). It is effective, but the key rule to remember is that it isn’t a filter — you either pass or fail for a given key in the parent-child relationship. You can’t allow access to a lower part of the tree if you don’t have access to the upper part — it isn’t a filter. I’m saying that twice here because the Firebase documentation says it a billion times and I still didn’t get it for the first 24 hours of working with the security model. This leads to some strangely structured data — sharding out public vs private data, for example. You just don’t do this type of work in Redis because, well, there is no concept of users or end-user authentication. The other relatively neat part of the Firebase security model is that it allows for validation in the same structure — you can prevent nasty data from coming into your dataset using the same type of logic. It does drive me nuts that you must do this all in their web-based IDE as far as I can tell, but the world isn’t perfect, right?
Let’s talk cost.
Firebase is expensive. No bones about it. I think for most applications, you’ll be spending $49 USD / month. This includes 10GB of storage, which if you compare to a similarly priced plan at Redis Labs, you’ll see is generous. The real reason that you’ll be spending this much is not the storage but the number of connections. Since you’ll be having users directly connect to your Firebase store, you need unlimited connections — the next lower paid plan at $5 / month limits to 100 connections — maybe okay for testing, but I wouldn’t want something in production that could only handle 100 concurrent users. You also don’t even get private backups at $49 / month.
In conversations with one of my clients, I sheepishly mentioned the monthly cost and they were not phased. In a moment of rare client clarity, they said “How much time would it take you to get this running with a less expensive database?” I responded that it would take at-least an extra week of development time — do the math (with even a modest hourly rate) and your client just saved money by going with a more expensive database.
So, should you dump Redis and get a Firebase t-shirt?
In short “no.” This is a classic example of right-tool-for-the-right-job. If you are building an app that is primarily storage / retrieval with real-time needs, by all means, use Firebase. If you need to significantly manipulate or analyze data, pull data in from other sources, use Redis as your primary data store. Or use both. Nothing says that you can’t use Redis as your powerful data store engine and throw the results to the user over on Firebase.
What can Redis learn from Firebase?
The one thing I’d love to do is write a client / server JS / Node library that uses Redis but provides some of the nice baked-in components of Firebase. I can see being able to graft on a similar security model and potentially even build a keyspace notification-based system that can move to the client side. Alas, these are pipe dreams for today (unless someone wants to pay me to write it!).
This isn’t part of the Node / Redis series, but you might find it interesting if you got this far in this article.
