Полное руководство
Как создать приложение с помощью базы данных 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.