Последние два года я использую исключительно Firebase. Да, да, у меня есть кластер elasticsearch, и Redis кэширует некоторые мои данные, но Firebase - мой единственный источник правды.

В начале своей карьеры писателя Firebase я сделал кучу ошибок, большинство из которых были следствием плохих структур данных. Изучив принципы NoSQL и ограничения Firebase, я понял, что мне больше не нужны реляционные данные. Redis мне тоже не нужен. А firebase-queue сделала практически ненужными конечные точки REST!

ОБНОВЛЕНИЕ 30.06.2016. Я опубликовал свой бесплатный курс Firebase 3.0 для Интернета. Проверить это.

ОБНОВЛЕНИЕ 01.08.2016. Я объединил оба этих метода разбивки на страницы в один модуль Node.js / браузера под названием FirebasePaginator. Он находится на GitHub, доступен через NPM и Bower, и я записал быстрый скринкаст YouTube, чтобы вы его рассмотрели.

Структуры данных Firebase: введение

Это часть 1 серии Medium о структурах данных Firebase. Понятия не имею, сколько частей напишу. Есть о чем рассказать.

Зачем нужны структуры данных Firebase? Потому что большинство разработчиков, включая меня, имеют опыт работы с SQL, где мы думаем о данных в терминах таблиц. Это мышление не переносится на решение NoSQL, такое как Firebase, и приводит к ряду общих вопросов.

  • Как мне разбить на страницы?
  • Как управлять сложными структурами данных?
  • Почему мои запросы медленные?
  • Что это за правила безопасности?
  • Разве с SQL все это не проще ???

Плохие новости

  • Ваш опыт работы с SQL здесь не поможет.
  • Шутки в сторону. Забудьте все, что вы узнали о SQL.

Хорошие новости

  • Вышеупомянутые вопросы - все решенные проблемы.
  • Когда я закончу, тебе ничего не понадобится, кроме Firebase.
  • Возможно, вы готовы навсегда отказаться от SQL.
  • Я люблю отвечать на вопросы, так что спрашивайте меня что-нибудь в Twitter по адресу Chris Esplin, прокомментируйте этот пост или присоединяйтесь к новому Firebase Slack Channel!

Хорошо, начнем с разбивки на страницы.

Запросы Firebase требуют эффективности

SQL позволяет запускать всевозможные ужасно неэффективные запросы. Вы можете остановить свою БД парой паршивых соединений.

Firebase работает в реальном времени, масштабируется как безумно и не может позволить вам совершать подобные ошибки. Вот почему запросы Firebase так ограничены. Сначала это кажется проклятием, но поверьте мне. Пожалуйста верь мне. Это замаскированное благословение.

Если вы не знакомы с запросами Firebase, прочтите здесь:

Https://www.firebase.com/docs/web/api/query/

Разбивка на страницы

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

В любом случае.

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

Мелкие ключи: https://demos-firebase.firebaseio.com/dataDemo/names.json?shallow=true

Данные: https://demos-firebase.firebaseio.com/dataDemo/names.json

Обратите внимание, что в файле names-shallow.json нет отсортированных ключей. Это критично! Обычный ключ-значение JSON никогда не сортируется по ключу. Не может быть. Только массивы имеют порядок для них. Но в этом нет ничего страшного, потому что мы знаем, как использовать Array.prototype.sort ().

Следующий код использует библиотеку под названием Axios для выполнения HTTP-запроса на список мелких ключей. Я написал это для Node.js, но Axios и Firebase одинаково работают в браузере.

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

Примечания

Объяснение запросов Firebase

Все запросы Firebase начинаются с ссылки, например

var namesRef = new Firebase (https://demos-firebase.firebaseio.com/dataDemo/names);

Затем вы изменяете ссылку, используя методы запроса.

Первый метод запроса, который вам всегда нужен, - это orderBy.

  • orderByChild (‘some-child-name’): заказывает буквенно-цифровой код по любому дочернему ключу.
  • orderByKey (): заказы по ключу, обычно это причудливые «нажимные» клавиши, на которые я ссылался ранее.
  • orderByValue (): актуально, только если у ваших узлов нет дочерних узлов. Если ваш список не вложен, имеет только одно значение, а не подузлы, вам может потребоваться orderByValue ()
  • orderByPriority (): не используйте это. Фактически, не используйте никакие старые вещи $ priority. Firebase по-прежнему поддерживает его, но с помощью orderByChild () он не имеет значения.

Затем вам нужно решить, сколько записей вы хотите и в каком направлении вы хотите заказать.

  • limitToFirst (N): начинается с самой старой записи и читает по направлению к более новым записям
  • limitToLast (N): возвращает N результатов из самых новых записей в списке, но возвращает их в порядке возрастания, поскольку Firebase сортирует только в порядке возрастания. Итак, если у меня есть записи 1 ... 10 и я запускаю limitToLast (3), я получаю записи 8, 9 и 10 в таком порядке.

Наконец, решите, с какого ключа вы хотите начать или закончить.

  • startAt (‹someKey›): ключ, с которого следует начать чтение
  • endAt (‹someKey›): ключ, при котором прекращается чтение

В приведенном выше примере я перебираю 10 клавиш и нажимаю на клавиши 0, 3, 5, 7 и 9. Для каждого ключа я вызываю namesRef.orderByKey (). LimitToFirst (2) .startAt (key).

Таким образом, начало с 0-го ключа возвращает 0-й и 1-й результат. Начиная с 3-го ключа, возвращаем 3-й и 4-й результаты… и так далее.

Другой метод разбивки на страницы

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

Следующая партия…

Подробнее о сложных структурах данных и правилах безопасности.

И напишите мне в комментариях, в Твиттере, на новом Firebase Slack Channel… однако вы можете найти меня. Я люблю говорить о Firebase.