This content originally appeared on DEV Community and was authored by Denis Matafonov
Firebase cloud databases, and in particular Firestore, are seen as a convenient tool for building simple applications that use data from the internet. They are well-suited for quickly testing hypotheses, providing a ready-made server infrastructure and an easy-to-use SDK for client platforms. However, what if this SDK deviates from the paradigms we have established in our project?
Let’s take a look at how you can use Firestore through the REST API. This can be done using your existing stack. For example, in my Android project, I used Retrofit, Coroutines, and more. Additionally, you can work with the RPC API as well.
Connection
To work with Firestore in this way, you do not need dependencies on Firebase services. Firestore itself says that using the REST API is just in case you don’t want to drag the full library.
To connect to the “production” version of the databases, you can use one of the authentication methods. In the test mode, API endpoints are open to everyone.
The base URL becomes a string like https://firestore.googleapis.com/v1/projects/YOUR_PROJECT_ID/databases /(default)/documents/, where YOUR_PROJECT_ID is the name of your project in Firebase. ‘/documents` is actually just one of the groups of methods, but today we are interested in it, because CRUD operations are performed through it.
For requests to document collections, the names of the collections are added to this base URL, and its id is also added to access a specific element. For example, `cities/LA’.
Processing
It is important that these are collections of documents, not tables. There can be any number of fields inside the elements. Therefore, we allow converters to replace missing fields with null ones and not be afraid of new fields:
Json {
explicitNulls = false
ignoreUnknownKeys = true
}
Now you can (almost) feel free to create new documents with a new structure – without migrations and other adventures.
When requesting a collection, we will receive the following response:
In addition to the collection itself (documents), other fields may be received in the object, for example, a pagination token. Please note that the fields of our records come in wrappers corresponding to their types, which is not very convenient for me.
Setting up queries
In the example above, we are implementing a news feed. The news should be sorted by the time they were created, with the most recent ones at the top. By default, Firebase Firestore returns records in order of their id. While it would be possible to number them manually, we will let the ids stay automatic. We can assume that we can use the “createTime” field provided by Firebase in the document.
There are two things to note here. The good news is that we can actually specify an “OrderBy” query parameter to sort our records. However, the bad news is that this can only be done using existing fields. Therefore, we need to add “createTime” to our fields ourselves.
To do this, we use the following parameter: @Query("orderBy") orderBy: String = "createTime desc". Note that the sorting direction is not a separate parameter, but is included with the field.
Pagination
Firestore allows you to upload data in batches. To do so, you can add the query parameter pageSize to specify the number of items in each batch, and pageToken to get the next page of results. This allows you to use pagination tools like Paging3, which have their own advantages.
Overall
Using Firestore via its REST API doesn’t limit you from using its features. In fact, it can be integrated with a standard networking stack. This might be an additional reason to consider using it for your product or learning project.
This content originally appeared on DEV Community and was authored by Denis Matafonov