Firebase: Farewell to Illusions

Marketing has become part of the development world. By the number of stars on GitHub they determine which of the similar solutions is cooler, and by the number of tweets you can predict which technology will develop in the next six months. In such circumstances, we risk becoming victims of hype, which we in Live Typing did, taking Firebase for the Holy Grail that can solve all the problems at once: collecting statistics, integrating chats, choosing a database, quickly developing MVP. When I came across this service in battle, I realized that my idea of ​​Firebase was so different from reality that understanding the scope of the technology was a real revelation for me. I want to share this understanding and how to use Firebase properly anyway.



I had a desire to work with Firebase a long time ago, but I was waiting for a suitable project. And I waited: MVP office reservation system. Since this is MVP, the backend business logic is pretty 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 later.

But first, I would like to eliminate all misunderstandings. Here are two things you need to learn to work with Firebase:

1. 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 unattainable so far;
2. it is NoSQL with all its advantages and disadvantages.

Choosing a solution for data storage should be based on the nature of the data itself. Firebase has its drawbacks:

• its scope is much smaller than the NoSQL solution;
• Firebase greatly limits you when fetching data and, if necessary, write data to several places at the same time;
• far from all data structures it is convenient to work in Firebase.

But a tool that allows you to quickly start developing MVP and having many more advantages is a pity to throw to the dump. And weaknesses can be patched if they interfere with you.

Preamble

Imagine that you are developing a reservation system for a hotel chain.



There are such entities:

• hotel
• number
• client
• reservation

How to implement this on an SQL database is understandable: four tables with links, and the point is in the hat.

How to implement this on NoSQL (Firebase)? You can try to nest entities in each other:

{
  “отель”: {
    …
    “номера”: {
        “номер”: {
        ???
      },
      ...
    }
  }
}

Here questions begin to arise: is it worth investing all the bookings in a room? and where to invest customers? Etc. NoSQL's problem is often that data has to be duplicated.

There is a second option: try to use NoSQL in a manner similar to SQL and create root objects for each entity, and maintain communications by storing the id of other objects.

It is probably easier to deal with these problems in other NoSQL databases, but I did not find solutions for my tasks in Firebase.

Whatever option you prefer, they have the same problem: the inability to make a complex selection of data. What if you want to get a list of reservations for a particular client? These reservations may be embedded in different rooms and hotels, and if the structure is flat, then Firebase will not be able to filter the data by several parameters (this problem was even discussed at StackOverflow ). In general, if you want to make a selection by customer and reservation date, the Firebase SDK will not help you.

You can try to solve this problem on the backend, but then you have to pump out a selection 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. Our backend on Node.js and one of the tools described below can help us with this.

Elasticsearch

This is a JSON REST API search engine 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 official integration from Firebase . To start, you need to download the repository, install the dependencies and populate the config with the keys for Firebase.

In this solution, I found a few cons:

1. This is a standalone application on Node.js and is difficult to associate with a backend.
2. creating the right index for ElasticSearch is not easy, and you cannot do just one data synchronization with the Firebase database;
3. field types are assigned automatically.

Feel them in such a simple example. You have a list of buildings with their description and coordinates. ElasticSearch requires that the fields responsible for the geographical coordinates of buildings be declared as such in advance, at the stage of creating the search index. Integration of the engine with Firebase does not give control over this process, but simply synchronizes all data, automatically determining data types.

ElasticSearch is free and is deployed on its controlled service - this is a plus. But at the same time, there are a number of deployment and security issues 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 would be the removal of the search index or the entry of its data into it. Therefore, initially this port is open only for queries 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 rests with the developer.

Algolia

SaaS search solution. Paid, but with a free plan. The price list 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 readme, and it worked for me on the first try.

The integration looks something like this:

var algoliasearch = require('algoliasearch');
…
var client = algoliasearch(config.algolia.applicationID, config.algolia.apiKey); // инициализируем Algolia
var indexRooms = client.initIndex('rooms'); // инициализируем поисковый индекс Algolia
rooms.once('value', initInde); // rooms — это reference к объекту в Firebase
function initIndex(dataSnapshot) {
  var objectsToIndex = []; // Этот массив мы отправим в Algolia
  var values = dataSnapshot.val(); // Получаем значение snapshot’a
  for (var key in values) { // обрабатываем каждый room
    if (values.hasOwnProperty(key)) {
      var firebaseObject = values[key];
      firebaseObject.objectID = key; // id объекта в Algolia должен совпадать с ключом в Firebase
      objectsToIndex.push(firebaseObject); // добавляем в массив
    }
  }
  indexRooms.saveObjects(objectsToIndex, function(err, content) { 
    if (err) {
      console.log('error');
      return;
    }
    console.log('success');
    return;
  });
}

As a result, we get a search index in Algolia containing all the room objects from Firebase. Please note that during the import process, the data can be processed additionally, for example, pull up the hotel name from another object in the database.

After we created the index, we are not going to update it as a whole, so 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 few people will think of doing a large-scale project on Firebase (I hope).

In contrast to this dubious minus, we get a convenient admin panel with access to analytics, a search index and the nuances of search queries.
An important plus is the presence of an SDK for everything and everything - from mobile platforms to backend frameworks. I did not delve into the essence, but the iOS developer said: it is more convenient than REST.

I advise you to try Algolia: integration with Firebase is better, installation is easier, and in the end we get a console with analytics and SDK. I ignored the technical details and did not analyze the performance and speed, this is a complex and separate topic.

Summary

The benefits of this fairly simple system are tangible. We get:

• Firebase for storing data, all read operations and simple non-competitive requests;
• Node.js for all competitive requests and complex business logic + Algolia / ElasticSearch services;
• Algolia / ElasticSearch for searching and complex data retrieval.

There are all the advantages of Firebase, without the disadvantages of the need to duplicate data or organize complex and slow selections 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 select 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. True, some data will have to be duplicated, but exclusively in the search index itself, and not in the database.

With proper use of Firebase it becomes a perfectly acceptable solution for access and storage of data. Always remember that the data is primary, and if you choose the wrong data structure or way of working with them, you will face serious development problems.

I look forward to commenting on your stories about Firebase integration and article comments. Thanks!