Я люблю Firestore! Firestore - это гибкая, масштабируемая база данных NoSQL для разработки мобильных, веб-приложений и серверов из Firebase и Google Cloud Platform (источник). Я использую Firestore для большинства своих побочных проектов, мы можем создать базу данных с помощью пары щелчков мышью, быстро и легко! Однако чаще всего я смешиваю свою бизнес-логику с деталями реализации Firestore (сантехника), и это, как правило, не очень хорошая идея. Вот почему я создал fireorm!

Fireorm - это крошечная оболочка поверх firebase-admin (пока), которая упрощает жизнь при работе с базой данных Firestore. Fireorm пытается упростить разработку приложений, которые полагаются на Firestore на уровне базы данных, абстрагируя уровень доступа, предоставляя знакомый шаблон репозитория. Это в основном помогает нам не беспокоиться о деталях Firestore и сосредоточиться на самом важном: добавлении новых интересных функций!

Fireorm написан и может использоваться только в Машинописи (пока). Почему? Потому что я тоже люблю Машинопись! Я мог бы назвать много причин, по которым Typescript такой классный, но цель этой статьи не в этом. Хорошо, я знаю, о чем вы думаете, давайте поговорим о слоне в комнате:

Не мешает ли система типов Typescript ходу мысли Firestore NoSQL?

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

База данных NoSQL без какого-либо контроля над данными может превратиться в кустарные данные, которые уменьшают ценность данных.

- Стивен Ф. Лотт, 2017

При этом fireorm в значительной степени вдохновлен другими организациями, такими как TypeORM и Entity Framework. Идея в том, что мы:

1- определить нашу модель как простой класс JavaScript,
2- украсить нашу модель декоратором Collection fireorm, чтобы представить коллекцию Firestore и
3- использовать репозиторий нашей модели для выполнения CRUD »Операции с базой данных Firestore.

Это походило на сложную тарабарщину? Нет, обещаю! Давайте рассмотрим возможности fireorm на простом примере: создадим программу для выполнения операций CRUD с нашей (теперь уже вымышленной) базой данных рок-групп! Если интересно, здесь вы можете найти фиктивные данные, а здесь - пример со всеми операциями!

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

Чтобы использовать fireorm, сначала мы должны инициализировать наше приложение Firestore. Я не буду вдаваться в подробности, потому что Документация Firestore нас поддерживает. В итоге мы получим что-то похожее на это:

Модели

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

Легко, да? Это просто класс Javascript! Единственное ограничение здесь - каждая модель должна иметь строковое поле с именем id.

Коллекции

Отлично, у нас есть модель, но как мы можем взять нашу модель и сохранить ее в базе данных? В Firestore мы храним данные в D« ocuments » (который представляет собой просто набор пар ключ-значение), и эти документы организованы в Коллекции. Чтобы представить коллекцию C, мы можем просто украсить нашу модель декоратором fireorm Collection, и каждый экземпляр указанной модели будет действовать как документ Firestore.

Декоратор Коллекция связывает нашу Band модель с Коллекцией Firestore. Если в декоратор не передается имя коллекции, имя коллекции будет выведено путем множественного числа имени модели. Если нам нужно собственное имя коллекции, мы можем передать его в качестве первого параметра декоратора. Например, в @Collection('rockbands') Коллекция Firestore нашей модели Band будет называться rockbands.

Репозитории

У нас есть свои модели, у нас есть свои коллекции, но как мы должны выполнять операции CRUD? Вот для чего нужны репозитории.

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

Репозитории Fireorm предоставляют необходимые методы для создания, извлечения, обновления и удаления документов из наших коллекций Firestore. Чтобы создать репозиторий из коллекции, мы можем просто вызвать метод getRepository fireorm. Примечание: для использования репозитория модель должна иметь декоратор Collection, иначе будет выдана ошибка.

Fireorm также помогает нам в создании простых и сложных запросов с добавлением методов whereEqualTo, whereGreaterOrEqualThan, whereGreaterThan, whereLessOrEqualThan, whereLessThan и whereArrayContains. Мы можем передать столько методов, сколько нам нужно для выполнения сложных запросов, при условии, что мы не забудем в конце вызвать метод find.

Имейте в виду, что fireorm не может обойти ограничения запросов Firestore, нам все равно нужно создавать индексы, если мы хотим создавать запросы, которые включают более одного поля.

Подколлекции

Fireorm поддерживает Подколлекции Firestore. Чтобы добавить Подколлекцию в нашу Коллекцию, мы добавляем свойство Подколлекции типа ISubCollection ‹T› с Декоратором Подколлекции (где T - модель нашей Подколлекции и первый параметр декоратора). Как и в случае с Декоратором коллекции, имя вложенной коллекции будет выведено и может быть переопределено вторым параметром декоратора.

Например, давайте создадим Albums модель и добавим ее как Подколлекцию Band:

В этом случае мы создали модель под названием Album для хранения информации о каждом альбоме: уникальный идентификатор (помните, модели должны иметь идентификатор по дизайну!), Название альбома и год выпуска альбома. После создания модели мы добавляем aalbumsproperty к существующейBand модели и украшаем ее с помощью декоратора Fireorm SubCollection, передавая Album model в качестве первого параметра.

Ограничения

Подколлекции можно использовать только в экземплярах, возвращаемых fireorm. Например, если мы хотим получить все альбомы Red Hot Chili Peppers, выпущенные после 2000 года, мы должны сначала получить информацию о группе, а затем найти Album Подколлекцию:

Надеюсь, это ограничение будет снято с версией 1.0.0, так что следите за обновлениями!

Пользовательские репозитории

Сейчас в наших репозиториях есть только методы CRUD. Что, если мы хотим добавить дополнительную логику доступа к данным? Fireorm поддерживает настраиваемые репозитории. Пользовательский репозиторий - это класс, расширяющий BaseRepository ‹T› (где T - модель) и украшенный декоратором Fireorm CustomRepository.

Теперь getRepository(Band) вернет настраиваемый репозиторий с методом getProgressiveRockBands. Если у модели нет настраиваемого репозитория, будет возвращен базовый репозиторий. Fireorm также предоставляет помощники getCustomRepository и getBaseRepository, если мы не хотим поведения по умолчанию.

Документация

Вы можете узнать больше о функциях fireorm, изучив различные примеры в репозитории github. Вы также можете взглянуть на api docs.

Скоро будет

Вы можете увидеть предстоящие функции в дорожной карте.

Специальная благодарность

Спасибо Максимо Домингесу за то, что помог мне преодолеть все проблемы дизайна при написании этой библиотеки.

Me kité (🇩🇴slang).