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

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

Почти 2 года назад я наткнулся на проект, где Firebase.io был ключевым компонентом в архитектуре. Я слышал о Firebase.io, но впервые собирался работать с этим инструментом. Enterprise Architect клиента был продан на 200%.

Я не буду (не могу) поделиться всей архитектурой, но то, что мне действительно не понравилось, это то, как он выбрал дизайн Firebase.io.

Позвольте мне начать объяснение того, что мы здесь видим, и на этой диаграмме есть 3 ключевых аспекта:

  1. Firebase.io используется для хранения определенных пользовательских данных, которые затем передаются всем клиентам (веб-клиенты, встроенные в React, приложения для iOS и Android).
  2. Если какой-либо из этих клиентов захочет выполнить обратную запись в приложение (что может быть транзакцией), ему придется использовать API.
  3. Все записанные данные хранились в MongoDB (и в некоторых других системах по необходимости), а для отправки данных в Firebase.io использовался триггер/push.

За время работы над проектом я узнал о следующих причинах использования Firebase.io, как это описано здесь:

  1. Существуют пользовательские данные, к которым пользователь будет получать доступ по различным каналам — они могут войти в систему через веб-сайт или через любое из имеющихся у них мобильных устройств (предполагается, что у любого данного пользователя будет >1 устройство). Нам нужно будет выполнять вызовы API для всех этих интерфейсных каналов каждый раз, когда пользователь меняет свое устройство.
  2. Кроме того, если есть действие пользователя, которое приводит к изменению их данных, мы не можем эффективно использовать кэширование, и все вызовы API будут направляться в базу данных.
  3. API не очень хорошо масштабируются для того количества пользователей, которое у них было (около 4 миллионов пользователей).
  4. Архитектура, основанная на серверах, осталась в прошлом, и нам нужно полностью отказаться от серверов. Видение состоит в том, чтобы переместить все части кода, которые могут быть, в безсерверный компонент (лямбда или другой), и Firebase.io был как раз одним из них.

Ну, когда я это увидел, у меня зазвенели колокольчики. Что-то мне подсказывало, что не все в порядке. Тот факт, что этот парень считал, что API плохо масштабируются или мы не можем эффективно кэшировать, не имеет смысла. Я имею в виду, что я пришел из систем, где мы писали API и масштабировали их до огромных размеров. Было ли это легко — НЕТ. Было ли это просто — нет. Но проекты не были проверены, а с появлением шлюзов API и кэширующих сборок эти проекты становятся проще. А тот факт, что мы уже использовали Kubernetes и Docker для создания наших микросервисов, это утверждение меня озадачило.

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

  1. Когда клиенты собирались загружать данные напрямую из Firebase.io, где должна была размещаться бизнес-логика?. Как вы уже видели, для отправки необработанных данных из MongoDB в Firebase.io требовалось простое нажатие триггера. Итак, когда нам нужно было добавить какую-либо бизнес-логику, мы будем дублировать ее во всех клиентах. Мое беспокойство было простым — мы создавали 3 клиентских слоя (React, ios native и android native), и если бы у нас не было уровня бизнес-логики, то вся логика дублировалась бы, и любое изменение/улучшение потребовало бы 3-кратного усилия.
  2. Думали ли мы о деплойментах и ​​о том, как будем делать сине-зеленые релизы? Нет слоя поверх данных, поэтому мы не можем управлять версиями API и делать параллельные выпуски. Кроме того, не было версий данных, так как же все это будет работать? Что ж, на это не было ответа, и меня попросили не беспокоиться об этом, и мы вернемся к этому позже.
  3. Как мы защищаем базу данных? Я имею в виду, что каждый пользователь будет подключаться к этой базе данных и будет делать запросы для чтения данных. Это не похоже на то, что у нас есть API, который абстрагирует пользовательские соединения для чтения данных. (Firebase.io имеет очень надежную структуру для решения этой проблемы). Что ж, ответа на этот вопрос также не существовало, поскольку он не был понят, и на самом деле это стало задачей для команды, чтобы выяснить это.
  4. Вы оценили стоимость услуги?
  5. Вы выяснили, будет ли сервис масштабироваться для удовлетворения ваших потребностей?
  6. …
  7. И еще несколько вопросов в этом списке.

И тут я спросил…

Работали ли вы над этим в прошлом и есть ли у вас достаточный опыт? Ответ был: «Нет, не я. Но в моей предыдущей компании я видел, как моя команда использовала это с большим успехом». Это было еще одним беспокойством для меня. Был выбран ключевой компонент, и работа началась, а у главного архитектора не было опыта работы с технологией. Меня беспокоило не использование новой технологии (я имею в виду, что мы все меняли технологию в какой-то момент нашей карьеры). Я боялся, что он не потратил время, чтобы ответить на все нюансы вокруг технологии, и если это сработало хорошо?

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

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

Ну, мы потратили 2 дня, чтобы решить вопросы. это было простое исправление, но нам потребовалось 2 дня, чтобы убедиться, что на этот раз мы все поняли правильно. Кроме того, учитывая, что это был онлайн-сервис с его дросселями и дизайном, мы не могли провести какие-либо традиционные тесты производительности. служба просто заблокировала бы нас. Итак, мы использовали несколько очень «креативных» способов создания нагрузки (например, 10 человек одновременно запускали скрипты на своих локальных ноутбуках). Ну, это было решено, но некоторые из нас работали 48 часов подряд. База данных также была защищена, и прошел год, а приложение держится хорошо. С тех пор я перешел к другим обязательствам, но я знаю, что затраты на обслуживание этих услуг были чрезмерными, и клиенты в какой-то момент хотели посмотреть, что мы можем здесь сделать (и, насколько я знаю, было только на 40%). их пиковое использование).

Приложение все еще находится в ведении, и есть большая команда из 12 человек, которая вносит небольшие изменения. Большая часть проблемы заключается в том, что в команде нет разработчиков с полным стеком, поэтому у нас есть по 2 каждого — iOS, Android, React, бэкэнд (java и node.js), а затем QA. Даже если бы мы заменили всех их разработчиками с полным стеком, нам все равно нужно было бы вносить изменения 3 раза в 3 слоя. любая новая разработка по-прежнему требует в 2-2,25 раза больше усилий (поскольку каждая новая функция не требует реакции). Бизнес недоволен, так как затраты на усовершенствования высоки, и они хотят, чтобы мы их сократили.

Есть сообщения, что иногда приложению требуется 10+ секунд для загрузки данных. Что ж, вызова API нет, данные синхронизируются напрямую с помощью Firebase.io, но я предполагаю, что команда, которая научилась на работе, снова неправильно использовала систему, и теперь запросы, которые выполняются в Firebase.io для загрузки данные просто работают медленно. Что-то мы еще не разобрались.

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

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