DEV Community: Denis Matafonov

Loading lists from the Firestore REST API: as if it were your own server

Denis Matafonov — Sun, 10 Aug 2025 07:23:17 +0000

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.

Грузим списки с Firestore REST API: как будто свой сервер

Denis Matafonov — Sat, 09 Aug 2025 19:15:29 +0000

en version: https://dev.to/dekabrsky/loading-lists-from-the-firestore-rest-api-as-if-it-were-your-own-server-532a

Облачные базы данных Firebase, в частности Firestore, принято считать удобным инструментом для реализации простых приложений с данными из сети, они хорошо подходят для быстрой проверки гипотез, предоставляя нам готовую серверную инфраструктуру и удобный SDK на платформах-клиентах. Но что если этот SDK для нас - отклонение от принятых в проекте парадигм?

Давайте посмотрим, как можно использовать Firestore REST API. Его можно использовать с привычным вам стеком, например, в моем проекте на Android это были Retrofit, корутины и так далее. Кстати, можно работать и с RPC API.

Подключение

Для такой работы с Firestore не нужны зависимости на сервисы Firebase. Сами Firestore как раз и говорят, что использование REST API - как раз на тот случай, если вы не хотите тащить полную библиотеку.

Для подключения к "продовой" версии баз можно воспользоваться одним из способов аутентификации. В тестовом режиме эндпойнты API открыты всем.

Базовым URL становится строка вида https://firestore.googleapis.com/v1/projects/YOUR_PROJECT_ID/databases/(default)/documents/, где YOUR_PROJECT_ID - имя вашего проекта в Firebase. /documents, на самом деле, только одна из групп методов, но сегодня нас интересует именно она, ведь через нее выполняются CRUD-операции.

Для запросов к коллекциям документов к этому базовому URL добавляются названия коллекций, для доступа к конкретному элементу - еще и его id. Например, cities/LA.

Обработка

Важно, что это именно коллекции документов, а не таблицы. Внутри элементов могут быть какой угодно состав полей. Поэтому разрешаем конвертерам подменять отсутствующие поля null'ами и не бояться новых полей:

Json {
    explicitNulls = false
    ignoreUnknownKeys = true
}

Теперь можно (почти) не стесняться создавать новые документы с новой структурой - без миграций и прочих приключений.

При запросе коллекции нам придет следующий ответ:

Кроме самой коллекции (documents), в объекте могут приходить другие поля, например токен для пагинации. Обращаем внимание, что поля наших записей приходят в обертках, соответствующих их типам - не очень удобно.

Настраиваем запросы

В примере выше я реализую новости. Новости должны сортироваться по убыванию времени создания - новые в начале списка. По умолчанию Firestore отдает записи отсортированными по id. Можно было бы конечно им давать номера по порядку, но пускай id остаются автоматическими. Логично предположить, что можно воспользоваться предоставляемым самим Firestore полем createTime в документе.

Тут две новости, хорошая и плохая. Хорошая - действительно можно указать query-параметр orderBy и отсортировать наши записи. Плохая - это можно сделать только по полям из fields. Соответственно, нужно добавлять в наши поля createTime своими силами.

Параметр получается следующий: @Query("orderBy") orderBy: String = "createTime desc",. Да, направление сортировки - не отдельный параметр, а живет вместе с полем.

Пагинация

API Firestore позволяет загружать данные порциями, для этого следует добавить в запрос query-параметры размера порции pageSize и токен следующей страницы, полученный из страницы предыдущей - pageToken. Теперь можно использовать, например, Paging3 с его преимуществами.

Итого

Использование Firestore через его REST API не ограничивает нас в использовании его функциональности, при этом становится возможным использовать его со стандартным стеком, связанным с работой с сетью. Возможно, это лишний повод рассмотреть его в своем продуктовом или учебном проекте.