Полное руководство

Как создать приложение с помощью базы данных Firebase

Разработка приложений с безболезненной облачной серверной частью

Многие амбициозные разработчики приложений мечтают реализовать свои инновационные идеи, не беспокоясь о технических деталях. В действительности настройка хранилища данных для разработки приложений может быть сложной задачей, задачи по предоставлению серверной базы данных, написанию сценария схемы базы данных и запросов SQL потребуют значительных усилий.

Хорошая новость заключается в том, что появление облачных сервисов, таких как Firebase, позволяет нам легко помещать данные приложений в облако с помощью всего лишь нескольких вызовов функций. В этой статье я расскажу, как использовать Firebase Data Store и как интегрироваться с приложением. Вместе с публикацией я проиллюстрирую идею на примере, чтобы показать, как я конвертирую свое приложение из локальной базы данных SQLite в хранилище данных Firebase на облачной платформе.

Это вторая часть моего рассказа о том, как использовать сервисы Firebase для разработки приложений. Вы можете обратиться к моей предыдущей статье Firebase - способ ускорить реализацию аутентификации вашего приложения, в которой содержится пошаговое руководство по реализации входа и входа в социальные сети с помощью службы аутентификации Firebase. .

Что такое база данных Firebase?

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

База данных Firebase - это база данных на основе документов в формате JSON, изначально поддерживаемая javascript. Его удобный для разработчиков SDK значительно упрощает интеграцию приложения с помощью всего нескольких вызовов функций. Поскольку базовая облачная инфраструктура работает на платформе Google Cloud Platform, она предлагает уровень обслуживания корпоративного уровня - высокую доступность и автоматическое масштабирование емкости.

База данных Firebase имеет 2 варианта: База данных в реальном времени и Cloud Firestore. В общем, Firestore подходит для большинства целей, поскольку он предлагает функциональные возможности высокого уровня, тогда как база данных Realtime Database - это внутренняя база данных для приложений, которым требуется доступ к API более низкого уровня. Вы можете заполнить этот опрос, который поможет вам решить, какой из них подходит для вашего варианта использования.

В этой статье я подробно рассмотрю реализацию Firestore на примере.

Настройка базы данных Firebase

Для начала давайте сделаем несколько шагов по настройке базы данных Firebase. Во-первых, вам нужно создать проект в консоли Firebase, если у вас его нет. Затем просто нажмите кнопку «Создать базу данных», чтобы активировать службу в консоли Firebase. Firebase предлагает одну базу данных для каждого проекта бесплатно, ограниченный размером данных 1 ГБ, с ежедневным объемом чтения 50 КБ, записи 20 КБ и удалением 20 КБ. Этого бесплатного предложения достаточно для разработчиков, чтобы начать свою инициативу без необходимости платить за услуги инфраструктуры.

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

Теперь все готово, и база данных готова к использованию! Затем давайте посмотрим на настройку схемы данных.

Структура данных Firestore

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

Firestore состоит из коллекций документов. Данные, хранящиеся внутри каждого документа, представляют собой пару «ключ-значение». Кроме того, он поддерживает вложенную структуру, так что мы можем хранить коллекцию документов в каждом документе. На схеме ниже показано, как выглядит структура данных:

Пример приложения - приложение для отслеживания расходов

Если взять в качестве примера мое приложение Expense Tracker, это приложение предназначено для отслеживания моих ежедневных расходов. Изначально я создал это приложение, используя базу данных SQLite в качестве внутреннего хранилища данных со схемой взаимосвязей сущностей ниже:

Структура данных проста и понятна, каждая запись о расходе связана с категорией расходов и методом оплаты. Идентификатор метода платежа и идентификатор категории в записях о расходах являются внешним ключом для поиска подробной информации о способе и категории платежа. Интересно, что категории расходов имеют отношения между родителями и детьми сами по себе, что означает, что категория может иметь свои собственные подкатегории. Например, я могу определить категории расходов - «Личные» и «Семейные». «Семья» имеет подкатегории, такие как «Счета», «Жилье», «Транспорт» и т. Д., В то время как «Личный» имеет подкатегории, такие как «Завтрак», «Обед» и т. Д.

Я определил 3 коллекции документов для преобразования таблиц реляционной базы данных в Firestore со схемой ниже:

  • Пользователи и расходы - это отличная функция с добавленной стоимостью, позволяющая разделить записи о расходах по пользователям для поддержки нескольких пользователей. У каждого пользователя будет своя собственная коллекция записей о расходах. Эта функция возможна благодаря возможности облачного хранилища данных.
  • Категории расходов - исходные родительско-дочерние отношения сохраняются во вложенной структуре документа.
  • Способы оплаты - легко переместить таблицу способов оплаты в собрание документов.

Средство просмотра данных Firebase

Мы можем просматривать и поддерживать данные в консоли Firebase. Это удобная функция для разработки и обслуживания.

Мы можем перейти дальше во вложенную структуру документа. Например, просмотр записей о расходах конкретного пользователя. Идентификатор расходной записи - это случайный код на основе UUIDv4. Конечно, только авторизованное лицо может получить доступ к консоли Firebase в производственной среде.

Контроль безопасности данных

Контроль доступа к данным важен для того, чтобы гарантировать, что весь доступ к данным аутентифицирован и авторизован. Реализация традиционной базы данных обычно зависит от логики приложения. Таким образом, управление доступом к данным объединено в логику приложения. Однако логика приложения была бы сложной, дефекты в логике приложения могли бы каким-то образом привести к лазейке, позволяющей неавторизованный доступ к данным.

Правила безопасности

Не беспокойтесь, Firebase решает эту проблему и упрощает контроль безопасности, отделяя правила безопасности от логики приложения. Мы можем определить набор независимых правил безопасности в Firestore для ограничения доступа к данным. Разделение управления доступом к данным является ценным и полезным для разработки приложений и текущего обслуживания, поскольку разработчики могут тестировать и разрабатывать правила безопасности как отдельный компонент. Разработка логики приложения больше не влияет на контроль безопасности данных.

Правило безопасности имеет форму декларативного определения, его легко понять, и Firebase также предоставляет удобную консоль для разработчиков, чтобы создавать правила. Рассмотрим на примере правила безопасности приложения Expense Tracker:

  • Разрешить доступ только для чтения к категориям расходов и способам оплаты для аутентифицированных пользователей
allow read : if request.auth != null
  • Прошедшие аутентификацию пользователи могут иметь доступ для чтения / записи к своим записям о расходах в коллекции, такой же, как и их адрес электронной почты (например, идентификатор пользователя).
allow read, write : 
if request.auth != null 
&& request.auth.token.email == userId

Вот полный набор правил безопасности:

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

Инструмент разработки правил безопасности

Вы можете разработать правила безопасности в своем любимом редакторе, поскольку они представляют собой текстовый контент. Кроме того, консоль Firebase предоставляет разработчикам удобный пользовательский интерфейс для тестирования и устранения неполадок правил безопасности. В случае сложных правил безопасности вы можете настроить локальную среду на своем ПК для проверки правил.

Интеграция приложений

Наконец, пришло время склеить приложение и серверную базу данных. Благодаря удобному для разработчиков SDK доступ к базе данных Firebase прост. Опять же, я объясню пример исходного кода моего приложения Expense Tracker, чтобы показать, как инициализировать объект Firestore, выполнить запрос с критериями, сохранить и удалить расходы.

Инициализация

У меня есть служебный компонент ExpenseService, отвечающий за доступ к данным в базовой базе данных. Прежде всего, Expense Service должен инициализировать службу Firebase с конфигурацией JSON (firebase-api.json), которую можно сгенерировать из консоли Firebase. Это необходимо для того, чтобы Firebase SDK знал, что все последующие вызовы функций будут подключаться к нашему проекту Firebase.

Получить запись о расходах по диапазону дат

Чтобы приложение Expense Tracker отображало список записей о расходах за определенный период времени для текущего пользователя, мы сначала указываем на нашу целевую коллекцию документов и определяем критерии запроса. В этом случае мы можем проследить иерархию данных приложения: коллекция (пользователи) → документ (идентификатор пользователя) → сбор (расходы). Вот вызов функции:

collection("users")
.doc(loginId)
.collection("expenses")

Firebase выполняет правила безопасности для проверки доступа к данным на стороне сервера, поэтому вызов функции Firebase вызовет ошибку исключения и откажет в доступе, если доступ не соответствует требованиям правил безопасности.

Запрос данных в Firestore очень похож на SQL. Критерий определяется с помощью where () с сортировкой с помощью orderBy (). Мы можем определить составной запрос с несколькими условиями. Чтобы получить список записей о расходах с атрибутом даты в диапазоне дат в возрастающем порядке, вызовите функцию:

where("date", ">=", fromDate)
.where("date", "<=", toDate)
.orderBy("date")

Собираем все вместе:

Сохранить / удалить запись о расходах

Подобно функции запроса, SDK должен знать целевую коллекцию и документ. Затем операцию по сохранению и удалению записи о расходах можно просто выполнить, вызвав set () и delete () соответственно.

Последняя мысль

Постоянное хранилище данных является важным компонентом разработки приложений, независимо от того, простой или сложный вариант использования. Традиционная реализация серверной базы данных включает в себя подготовку базы данных, разработку SQL, построение REST API, а также интеграцию приложений. База данных Firebase предоставляет разработчикам быстрый способ включить хранилище данных серверной части, ее облачная платформа позволяет быстро предоставлять услуги, а ее веб-консоль удобна для разработчиков для настройки структуры данных и правил безопасности. Как только база данных будет готова, разработчики могут немедленно приступить к разработке функций приложения, не тратя усилий на разработку внутреннего SQL-запроса и REST API.