This content originally appeared on DEV Community and was authored by Denis Matafonov
Облачные базы данных 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 не ограничивает нас в использовании его функциональности, при этом становится возможным использовать его со стандартным стеком, связанным с работой с сетью. Возможно, это лишний повод рассмотреть его в своем продуктовом или учебном проекте.
This content originally appeared on DEV Community and was authored by Denis Matafonov