Marketing has become part of the development world. By the number of stars on GitHub, it is determined which of the similar solutions are cooler, and by the number of tweets, we can predict which technology will be developed in the next six months. In such circumstances, we risk becoming victims of HYIP, which we did in
Live Taiping , taking
Firebase as the Holy Grail, which can solve all problems at once: collecting statistics, integrating chats, choosing a database, quickly developing MVP. When I ran into this service in battle, I realized that my understanding of Firebase was so different from reality that my understanding of the field of application of technology became a real revelation for me. I want to share this understanding and how to use Firebase right after all.
I had a desire to work with Firebase a long time ago, but I was waiting for a suitable project. And waited: MVP office reservation system. Since this is a MVP, the business logic of the backend is rather primitive. In addition, a mobile application on iOS will be connected to Firebase. It looks like an ideal case for using the service, but during the implementation I had to face some problems, which will be discussed further.
But first I would like to eliminate all misunderstandings. Here are two things you need to learn to work with Firebase:
')
- This is not a backend, but a database. You can forget about those wonderful examples of applications on Firebase without the server side, this is still unattainable;
- This is NoSQL with all its advantages and disadvantages.
Choose a solution for storing data based on the nature of the data itself. Firebase has its drawbacks:
- its scope is much smaller than that of a NoSQL solution;
- Firebase severely limits you when retrieving data and, if necessary, writing data to several places at the same time;
- far from all data structures is convenient to work in Firebase.
But the tool that allows you to quickly start developing MVP and having even a lot of advantages, it’s a pity to dump it. And weak spots can be patched if they bother you.
Preamble
Imagine that you are developing a reservation system for a hotel chain.
There are such entities:
- hotel
- number
- customer
- booking
It is clear how to implement this in a SQL database: four tables with links, and the trick is done.
How to implement it on NoSQL (Firebase)? You can try to put entities into each other:
{ “”: { … “”: { “”: { ??? }, ... } } }
Then questions begin to arise: is it worth it to invest all bookings in the number? and where to invest customers? Etc. The problem with NoSQL is often that the data has to be duplicated.
There is a second option: try to use NoSQL in a way similar to SQL and create objects for each entity in the root, and maintain connections by storing the id of other objects.
Probably, it is easier to deal with these problems in other NoSQL databases, but I did not find solutions for my tasks in Firebase.
Whichever option you prefer, they have the same problem: the inability to make a complex sample of data. What if you want to get a list of bookings for a specific customer? These reservations may be invested in different rooms and hotels, and if the structure is flat, then Firebase will not be able to filter data by several parameters (this issue was even discussed on
StackOverflow ). In general, if you want to make a selection of the client and the date of booking, Firebase SDK will not help you.
You can try to solve this problem on the backend, but then you have to download a sample of data filtered by one parameter and filter it further yourself. This is unacceptable.
What to do?
Do not use Firebase for complex data sampling. Your own Node.js backend and one of the tools below can help us with this.
Elasticsearch
This is a search engine with JSON REST API using
Lucene and written in Java. Details can be read on the
official website , and we will immediately begin to consider it in conjunction with Firebase.
Installation
You need to put ElasticSearch on the server (it will be easy to do this according to the instructions). After you need to integrate it with Firebase, namely, create a search index from the Firebase database. I used the
official integration from Firebase . To start, you need to download the repository, install dependencies and fill in the config with the keys for Firebase.
In this solution, I found several drawbacks:
- This is a separate application on Node.js, and is difficult to associate with the backend;
- creating the right index for ElasticSearch is not easy, and one cannot synchronize the data with the Firebase database;
- field types are assigned automatically.
Feel them on such a simple example. You have a list of buildings with their description and coordinates. ElasticSearch requires that the fields responsible for the geographic coordinates of buildings be declared as such in advance, at the stage of creating a search index. The integration of the engine with Firebase does not give control over this process, but simply synchronizes all the data, automatically determining the types of data.
ElasticSearch is free and takes place on its service-controlled - that's a plus. But at the same time there are a number of problems with deploem and security that need to be thought out in advance.
Example: The port used by Elastic Search for external queries is open. This creates a vulnerability, since the same port is used to record and manage search indexes. A possible result of such an oversight is the removal of the search index or the entry of its data into it. Therefore, initially this port is open only for requests from the same machine on which ElasticSearch is installed.
We conclude: the question of how to implement the interaction between the user, ElasticSearch and the backend, falls on the developer’s shoulders.
Algolia
SaaS search solution. Paid, but with a free plan. Price and other details can be found on the
official website .
Integration with Firebase is implemented using the
official js-library . The installation and launch process is described in detail in the readme, and everything worked for me on the first attempt.
The integration looks like this:
var algoliasearch = require('algoliasearch'); … var client = algoliasearch(config.algolia.applicationID, config.algolia.apiKey);
As a result, we get a search index in Algolia containing all the objects of rooms from Firebase. Please note that during import data can be processed additionally, for example, pull up the name of the hotel from another object in the database.
After we have created the index, we are not going to update it entirely, therefore, in the future, we monitor the events in Firebase and process them:
rooms.on('child_added', addOrUpdateObjectRooms); rooms.on('child_changed', addOrUpdateObjectRooms); rooms.on('child_removed', removeIndexRooms);
The only downside to using Algolia is that you have to pay for SaaS. But for MVP, a free tariff should be enough, and a large-scale project on a Firebase will occur to very few people (I hope).
In contrast to this dubious minus, we get a comfortable admin panel with access to analytics, a search index and the nuances of search queries.
An important advantage is the presence of the
SDK for everything and everyone - from mobile platforms to backend frameworks. I didn’t go into the essence, but the iOS developer said: this is more convenient than REST.
I advise you to try Algolia exactly: integration with Firebase is better, installation is easier, and in the appendage we get a console with analytics and SDK. I ignored the technical details and did not analyze the performance and speed, it is a complex and separate topic.
Results
The benefits of this rather simple system are tangible. We get:
- Firebase for storing data, all read operations and simple noncompetitive requests;
- Node.js for all competitive requests and complex business logic + Algolia / ElasticSearch services;
- Algolia / ElasticSearch for searching and complex data selection.
There are all the advantages of Firebase, without the disadvantages of having to duplicate data or organize complex and slow samples on Node.js. In this scenario, you can easily implement a booking system or any other task that requires transactions and complex data samples. For example, you can first pick up a room for a specific day for two people, with air conditioning and a balcony, and then book it and not be afraid that the room has already been occupied or will be occupied again. Some data, however, will have to be duplicated, but only in the search index itself, and not in the database.
With proper use of Firebase, it becomes an acceptable solution for accessing and storing data. Always remember that data is primary, and if you choose the wrong data structure or way to work with them, you will face serious problems in development.
I am waiting in the comments of your stories about the integration of Firebase and comments on the article. Thank!