Experimenting with firebase
Firebase is a back-end as a service platform with a database which happens to react in real time. It has been bought by Google in October 2014. I gave it a try and here’s what I thought.
- Authentication: Good
- Realtime: Good
- Sorting data: Good
- Authorizations: Meh
- Pagination: Arf
- Filtering data: No (Or really simple)
- Query system: No
- VueFire: Only for the basics
- Relations: Hell no
When developing on a new project, especially connected projects (webApp, mobile…), you first have to think about the data, the way it’s stored, secured, backed-up and accessed. It require some extra skills that you may not know or have in your team or simply have no time to spend on. And if you need a real-time data synchronization, then you’ll have to build a full team just for that. Now, acquiring new skills is pretty cool, It’s mostly is the time which would be the problem.
Firebase has thought this through and provides a [full]? featured solution. It has a real-time DB, manages data storage, authentication providers, a hosting service and custom executions in the could, a nice documentation, and an API for the main languages (JS, C++, JAVA, SWIFT…).
Having this pre-built and ready to use is a real time saver. It’s free to test and to use. Since It’s on the cloud (AKA someone else’s computer), you won’t know where are your data and how they’re used.
The project is not interesting here. It’s a simple CRUD project, needing a templating system, route management, an authentication system, data filters and authorizations. Thinks we tend to find anywhere. I chosed to use Vue and VueRouter for the view part of the app, and has you now, Firebase for the API. Vue also has a wrapper for Firebase which is pretty handy. I chose view, because I know I can rely on it without affecting the Firebase client.
yarn add vuefire firebase
After adding the new dependencies to a basic vue-cli project, I configured the whole thing and it runs. I quickly made a few pages, used the provided auth system, displayed lists and there forms. The data is synchronized with the database, end of the story.
No. Doing this (which the easy stuffs right ?!) required me to tweek the default VueFire integration to properly load my data. It has to wait for a first item to load a second one. Seems pretty natural, but is actually impossible to put in place when using the VueFire integration.
Also having a reference on an item to an other one is really not easy to manage, yet I only have an A–>B relation here.
Finally, all the element depending on the same root, firebase downloads all subtrees on load. Trying to load a level 1 object, well, you’ll load all the associated content, and if it’s a chat channel, well, a lot of data. if you target an environment or a device with a low bandwidth, well it won’t work. As for pagination, well it’s a real pain since you cannot get the array length (without loading everything), and you cannot paginate while also sorting the content.
After managing those issues, I go deeper and start to manage the authorizations. Many of my items have an
author property, and I want to use it for the user to only see what he has authored. Long story short, you cannot use the authorizations system to filter the objects in a list.
So you can have a rule, on an item to allow only its author to red or write in it, but if you query the parent(s) node(s), you get the result ? Isn’t this a security issue ? BTW, there’s no way to filter sub element of the tree from the parent node either.
Ok, I’ll manage the filtering from the client, it’s dirty, but it’ll do the work for now. I start to check the documentation, for a way to specify filters on the data. First you can filter only one thing at once (not really good), and you cannot filter while sorting either.
That’s it, I quit, for now.
For a really simple project, it started to work pretty fast. Pushing and getting data is really easy if you’re ready to load the whole database on the client.
For as a full featured projects, with a real-time database, it’s sad to have one which happen to not be able to perform basic query logic.
This experiment helps me understand which projects Firebase would be useful for, and which it would not.
I did not have any comments on the pricing, the data management (migration, backup…) nor the stored functions since I could not get this far without rage quiting.
As the conclusion, i don’t think we should let Firebase off the hook so easily, but you should be considered this before getting into it. The project is really appealing, live data synchronization is great and the platform comes with a nice set a features, and for small projects it’s probably enough. From what I have seen, it saves a lot of setup work on a real time application, but Nodejs would be able to do everything firebase does, and a lot more securely. Also, when you cannot properly query and manage the data, it gets really hard for developers to work properly.