DmitrySkripkin Jan 24 2017 at 14:58

Firebase: прощание с иллюзиями

6 min

81K

Лайв Тайпинг corporate blogJavaScript*NoSQL*Node.JS*SQL*

Comments 34

ertaquo Jan 24 2017 at 15:10

Я недавно начал работать с Firebase (пробую писать кой-чего под Android). Мне в нем нравится то, что для моего приложения не нужно писать вообще ни байта серверного кода (за исключением правил для базы данных). Но огорчает ужаснейшая документация и отсутствие возможности сделать выборку элементов из базы по идентификаторам.
Кстати, вложенные сущности использовать наоборот не рекомендуется. Суть в том, что при подписке на какой-либо из ключей при изменении вложенных сущностей передаются вообще все данные этого самого ключа. Например, в отеле изменили данные о номере. Если вы были подписаны на "/отель/", то вам придут данные об этом отеле целиком, со всеми номерами и прочим. Если же внутри отеля хранить данные о бронях, то придут и брони. Короче говоря, трафик увеличивается в разы. Поэтому нужно хранить данные как-то так:

{
  "отели": {
    "id отеля": {
      ...
    }
  },
  "номера_отеля": {
    "id отеля": {
      "id номера": {
        ...
      }
    }
  }
}

Сумбурно описал, но надеюсь, смысл понятен будет.

AllexIn Jan 24 2017 at 15:25

Эмуляция реляционной БД?

ertaquo Jan 24 2017 at 15:39

Ага. Вот из доков кусок: https://firebase.google.com/docs/database/web/structure-data#flatten_data_structures
И подобный стиль работы используется и в официальных примерах.

DrPass Jan 24 2017 at 15:51

Поэтому нужно хранить данные как-то так:

Да дело в том, что это просто неподходящий инструмент для такой задачи. Если ваши данные имеют реляционную структуру, то и голову ломать не нужно, вам требуется реляционная СУБД. А подобные варианты — это забивание гвоздей крестообразной отвёрткой и закручивание шурупов молотком.

A_V_E Jan 24 2017 at 15:27

Придумать себе проблему, а потом ее героически преодолевать.

Вывод — не надо пихать NoSQL туда, где его использовать не стоит.

DmitrySkripkin Jan 24 2017 at 15:33

Вывод верный, без костылей на Firebase далеко не уехать. Однако есть и свои плюсы. Авторизация и роли, real-time, SDK под разные платформы и многие другие полезные фичи. Для MVP годится.

A_V_E Jan 24 2017 at 15:38

Просто изначально Ваша задача подразумевала реляционность. Использовать для нее нереляционную БД — это напрашиваться на усложнение архитектуры. В частности, неизбежное потом прикручивание поисковика — эластика/солр/люцены/etc, просто потому, что понадобилось добавить фичу чуть-чуть усложненного поиска — и тут noSQL ожидаемо ломается.

justboris Jan 24 2017 at 16:03

Firebase позиционируется как Backend as a Service. NoSQL — это детали реализации, на которые наступаешь только уже попробовав.

Посоветуете аналогичный сервис, только с SQL структорой данных?

A_V_E Jan 24 2017 at 18:03

В Backendless есть relations:

https://backendless.com/documentation/data/js/data_relations.htm

Плюс там есть поддержка внешних бд (поддерживаются пока только MySQL/MariaDB).

GennPen Jan 24 2017 at 15:40

Имейте совесть, не ставьте в следующий раз на КДПВ 10 мегабайтную гифку.

justboris Jan 24 2017 at 16:05

+1, не надо так, пожалуйста. Пара таких статей в ленте RSS — и квоте мобильного трафика на день придет конец.

Kanumowa Jan 25 2017 at 12:16

В настройках мобильного приложения можно включить загрузку картинок только через WiFi

LoadRunner Jan 26 2017 at 17:19

А можно и не включать. На десктопах 10-мегабайтные гифки тоже не вызывают фонтанов радости. На слабых компьютерах рендеринг повесит систему наглухо.

ostapbender Jan 24 2017 at 15:51

Хипстеры на марше.

Ради задачи, для решения которой (в виде MVP) за глаза хватит SQLite, притащили адовый ворох SaaS решений, потратили кучу времени на взаимное интегрирование всего барахла (без описания, конечно же, что, куда и с какими учетными данными за чем обращается), технично разложили грабли с денормализацией и дублированием данных, да помножили в своей этой Ноде все строки на картинки.

Оглушительный успех, я считаю.

xRay Jan 24 2017 at 16:09

да помножили в своей этой Ноде все строки на картинки

Это 5 с плюсом :)

UFO landed and left these words here

vintage Jan 25 2017 at 00:34

Почему? SQLite поддерживает транзакции.

i360u Jan 25 2017 at 12:09

Firebase — это, какбэ, далеко не только БД. А реализация собственной полноценной архитектуры/инфраструктуры дает не меньший простор для "ломания дров". Все вокруг такие умные, хипстерами обзываются, а сами никогда не лажают, ага.

UFO landed and left these words here

amaksr Jan 24 2017 at 17:43

Это статья как не надо становиться жертвой хайпа? гм…

vintage Jan 25 2017 at 00:31

OrientDB:

гибридная субд, хранящая грубо говоря JSON-ы с отношениями.
умеющая в права пользователей вплоть до права конкретному пользователю на чтение конкретной записи.
Поддежка REST и адаптеры под разные языки.
Lucene на равне с другими индексами, из коробки работает по любым полям.
Все данные хранятся в нормализованном виде.
Шардинг и репликация из коробки.
Веб админка тоже в коробке.
Простым запросом можно выбрать всё необходимое на нужный уровень глубины связей.
Может встраиваться в Java приложение.

Подробнее тут: https://habrahabr.ru/post/267079/

Riim Jan 25 2017 at 16:37

С ArangoDB не приходилось сравнивать? Сейчас между ними выбираю.

vintage Jan 25 2017 at 22:19

http://db-engines.com/en/system/ArangoDB%3BOrientDB%3BNeo4j
http://vschart.com/compare/arangodb/vs/orientdb

Фичи, которые есть в Orient, но нет в Arango:

Автоматические распределённые запросы. Ориент знает на какой ноде что лежит и сам делает map-reduce.
Прямые ссылки между документами. Это даёт простые запросы, быстрый переход по связям, удобное администрирование.
Возможность встраивания в Java приложение с доступом к низкоуровневым API.
Поддержка пессимистичных и оптимистичных блокировок.
Триггеры, правда мне в своё время не удалось прикрутить их ко внешнему приложению.
Fetch plan, позволяющий выбирать не только найденные узлы, но и связанные с ними по заданным правилам.
Более развитая поддержка графов.
Продвинутая система прав: пользователи/роли, записи/классы, чтение/запись/обновление/удаление, наследование.
Шифрованное хранилище.

Преимущества Arango:

Встроенный NodeJS со всеми вытекающими.

dim_s Jan 25 2017 at 10:40

ElasticSearch прекрасно может жить без Firebase как поисковой движок + база данных NoSQL.

iloveip Jan 25 2017 at 11:14

Мы на нашем сайте тоже используем Firebase для сервиса Банки http://www.iloveip.ru/banki/ и Algolia для поиска. Firebase работает в связке с таблицей Google, я писала об этом подробно на Хабре (https://m.habrahabr.ru/company/iloveip/blog/312232/). Для MVP Firebase действительно подходит, но в будущем мы будем от него отказываться. А вот к Algolia нет никаких вопросов, для поиска на статичном сайте этот сервис вполне устраивает.

iloveip Jan 25 2017 at 11:35

Прошу прощения, отправляла комментарий с мобильного, поэтому ссылки не поставились.

Вот пост на Хабре про использование Firebase https://habrahabr.ru/company/iloveip/blog/312232/

И ссылка на сервис http://www.iloveip.ru/banki/

i360u Jan 25 2017 at 11:44

ИМХО, для MVP вполне подходит вариант хранения связей по идентификаторам в сущностях. Проблемы возникают только если формат данных подразумевает большое количество связей и тогда это вопрос правильной категоризации. Firebase — это отличный инструмент, который позволяет реально быстро стартануть и многое дает из коробки (включая хостинг статики), но конечно подходит не на все случаи жизни. Не думаю, что его стоит в этом винить.

via-site Jan 29 2017 at 23:23

Последние несколько месяцев разрабатываю «Offline First Progressive Web App» (для работы с очень плохим или вообще без Интернета). С самого начала планировал использовать Firebase для быстрого старта.

Проблема возникла уже в самом начале, т.к. браузерный клиент Firebase не поддерживает полноценную офлайн работу. Лучшим решением что я смог найти оказался как бы порт CouchDB в браузеры — PouchDB и во всех современных (и не очень) браузерах он работает просто великолепно. Из коробки есть встроенная, автоматическая синхронизация с CouchDB (пока не проверял) или DBaaS сервисами типа: https://console.ng.bluemix.net/catalog/services/cloudant-nosql-db

Вот сейчас сижу и думаю: «зачем мне вообще использовать Firebase, если PouchDB — Simple Server — CouchDB / DBaaS CouchDB решают все мои проблемы?»

bioroot Feb 15 2017 at 19:39

И как там у couch-семейства с граблями? Мне в ближайшее время как раз предстоит работать над чем-то подобным, только со стороны backend'а. Хочется из коробки работы с Android/iOS и вменяемой поддержки клиентского js. Пока смотрю в сторону couchbase sync gateway. Но по ощущениям везде проблемы с реализацией контроля доступа, а мне как раз нужны фишки типа расшаривания документа одного пользователя другому. В этой штуке хоть channels есть.

via-site Feb 16 2017 at 12:25

Firebase позиционирует себя как BaaS (Backend as a Service), т.к. он предоставляет хоть какую-то настройку прав доступа + регистрацию/авторизацию/аутентификацию. Если клиент — это простой CRUD или что-то типа того, то мне кажется этого должно хватить.

CouchDB, Couchbase,… позиционируют себя как DBaaS (DataBase as a Service) и как мне известно все же требуют хоть какого-то сервера, на котором и будут определяться права доступа к базе.

Сначала хочу попробовать подружить PouchDB и Firebase. Сейчас не особо хочется заморачиваться с серверами. Но на перспективу все же смотрю в сторону независимой от сторонних сервисов архитектуры.

bioroot Feb 16 2017 at 16:49

Спасибо за ответ. Мне-то как раз сервер развернуть не проблема и вопрос скорее в том, какая технология что умеет. Пока couchbase sync gateway выглядит неплохим компромиссом. Но надо покопаться в нём глубже. Похоже что синхронизировать-то он синхронизирует (из коробки шлёт данные с мобильных устройств при изменении данных в Couchbase Light и обратно при изменениях на сервере), но при этом все данные довольно тупо прогоняются через sync метод и туда нужно зашить всю логику проверки данных и все сторонние операции, которые напрямую с обменом данными не связаны (логи писать, статистику собирать и т.п). В результате получается bottleneck и страшно как бы вся эта конструкция не развалилась под нагрузкой. Ну и отсутствие транзакций не добавляет радости (кстати, в Firebase они вроде бы есть, но я так до конца и не понял, как они устроены; похоже чуть ли не на лок все устройства, работающие с данными), хотя вроде бы есть какой-то механизм разрешения конфликтов. Но после долгого копания других достойных альтернатив я не нашёл.

bioroot Feb 15 2017 at 20:08

Про грабли Firebase неплохо написано здесь: Reasons Not To Use Firebase Хотя часть по-моему относится вообще к backendless-архитектуре. По началу она правда кажется прорывом, но в конечном итоге оказывается, что теперь всю логику надо реализовать на клиенте (т.е. минимум для iOS и Android, а может ещё и на продвинутом js-фреймворке под браузеры) и огребать все радости версионирования API, авторизации пользователя и прочего не в одном а сразу в двух-трёх местах. Так что пока backend рано выкидывать на свалку, на мой взгляд. Можно просто перераспределить часть логики с него на клиента, но разумно перераспределить.

P.S.: Это был комментарий ко всему посту, просто прилепился не туда…

Ekaterina_Kass Apr 25 2017 at 13:29

Отличная статья, спасибо!

polRk Jul 14 2019 at 06:43

У firebase есть две базы данных, realtime database и firestore. + Есть полноценный backend ( cloud functions ). Есть подписки, крон задачи и все, что необходимо доя mvp+++.