😢 Дорогостоящие ошибки: почему нам пришлось отказаться от Firebase

Статья публикуется в переводе, автор оригинального текста – Mohammad Faisal.

Шел 2018 год. У нас была крутая бизнес-идея, которая должна была принести миллионы (спойлер – не принесла 🙁). Но одной идеи для успеха недостаточно – нужно еще воплотить ее в жизнь, и чем быстрее, тем лучше.

Нашей маленькой команде из четырех человек нужен был самый простой и удобный инструмент для создания приложения. Мы начали искать (в основном в Google 👊) – и мы нашли Firebase!

Почему мы выбрали Firebase

1. Для приложения не требуется бэкенд, нужно лишь реализовать пользовательский интерфейс.
2. Большие возможности на бесплатном тарифе.
3. Отсутствует существенный порог вхождения.
4. Инструмент очень прост в использовании.
5. Включает в себя практически все, что нам необходимо.
6. И наконец, это продукт Google.

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

1. Firestore: масштабируемое решение для NoSQL баз данных в реальном времени, которое может использовать любой фронтенд.
2. Аутентификация: Firebase берет на себя все заботы по обеспечению аутентификации, и об этом можно вообще не думать.
3. Хранилище: мы его используем в основном для изображений.
4. Уведомления: очень простая в реализации служба уведомлений.
5. Хостинг: доступный и удобный хостинг статических сайтов. Мы размещали там наше фронтенд-приложение на React.
6. Функции: работают в облаке и могут реагировать на любые события на уровне данных. Мы их применяли в основном для отправки уведомлений.

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

Все шло просто замечательно, пока нам не пришлось наращивать масштабы. В команде появились новые разработчики, возникли проекты по улучшению панели мониторинга и админки. И все пошло… неправильно.

Противоречивые данные

Из-за NoSQL-природы Firebase Firestore не имеет никаких ограничений на формат хранящихся данных.

Когда кто-то из разработчиков добавил дополнительное поле или забыл проверить значение на null, все приложение упало.

Каждый раз при глобальном обновлении мы молились, чтобы не сломалось еще что-нибудь.

Чем больше разработчиков у нас появлялось, тем серьезнее становились проблемы. Каждая ошибка отнимала очень много времени – и это того не стоило. Чтобы сохранить продукт на плаву, приходилось работать день и ночь.

Каждая новая фича превращалась в кошмар.

Согласованность

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

У кого-то есть поле с именем user_id. Если кто-нибудь добавит другого пользователя с полем userId, это приведет к сбою всего приложения.

Нам приходилось манипулировать базой данных прямо из интерфейса, и было очень трудно проследить точную причину любой проблемы.

Объединение коллекций

Нет никакого способа соединить несколько коллекций для получения данных.

Например, у вас есть коллекция пользователей и еще одна с информацией об автомобилях, где хранится идентификатор владельца.

А теперь представьте, что вам нужно вывести список транспортных средств вместе с именем владельца.

В Firebase эта проблема решается следующим образом:

1. Загрузить первым запросом список автомобилей.
2. Для каждого из них получить идентификатор владельца.
3. Выполнить отдельный запрос для получения имени каждого пользователя.

А если нужно показывать еще какие-то данные? Может быть, лучше хранить информацию о владельце вместе с транспортным средством?

Дублирование данных

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

И теперь, когда нужно было вывести информацию, мы могли обойтись одним запросом.

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

При этом очень легко пропустить что-нибудь.

Сложность кода

По мере усложнения запросов, усложнялся и код интерфейса. Более того, нам пришлось писать все дважды – для мобильных устройств и для веба.

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

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

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

Теперь решение исходной проблемы само стало проблемой, ведь доступ и обновление данных осуществлялось сразу из трех мест.

Эффективность

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

Теперь каждый из разработчиков должен был делать все очень-очень осторожно, чтобы ничего не сломать. Мы ввели ряд правил и соглашений – потребовалось некоторое время, чтобы все привыкли и начали им следовать.

Цена

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

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

Смена технологии

Столкнувшись со всеми этими проблемами, мы решили наконец двигаться дальше.

Весь бэкенд приложения был переписан на Node.js и Postgres, а для хостинга мы теперь используем AWS.

Firebase же по-прежнему используется для аутентификации пользователей и уведомлений.

Значит, Firebase не подходит никому?

Короткий ответ – нет. Есть множество ситуаций, в которых Firebase отлично вам подойдет:

1. Прежде всего, это отличная технология для обучения. Если вы только начинаете свою карьеру, на примере Firebase можно легко познакомиться с технологией хранения данных.
2. Это удобное и простое решение для уведомлений и аутентификации пользователей.
3. Firebase позволяет разработчикам-одиночкам и маленьким командам очень быстро разработать полноценный проект.
4. Также она прекрасно подходит для создания небольших или внутренних проектов.

Однако если:

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

займитесь чем-нибудь другим. Для нас в такой ситуации Firebase стал очень неудачным опытом.