Действительно ли Firebase так хороша, как кажется?
взвешивая хорошее, плохое и раздражающее
Не поймите меня неправильно, мне нравится Firebase, но во всем, что связано с разработкой, всегда есть хорошие и плохие стороны, а также немного раздражающего, о котором никто не хочет говорить.
Что такое Firebase? Это универсальный облачный сервис Google, аккуратно упакованный и предоставляемый разработчикам, которым просто нужно что-то быстро запустить. Не нужно беспокоиться о выделении ресурсов или эластичных облачных структурах. Все, что вам нужно сделать, это подключить его к своему интерфейсу и альту! все просто работает.
Хотя это отлично подходит для быстрого прототипирования, управление затратами может выйти из-под контроля, если вы не будете осторожны.
Лично я работаю с Firebase последние два года над продуктами разной сложности. За последние два года я обнаружил интересные вещи о платформе, особенно о том, как думать и что это может значить для создания готового к работе приложения.
Без лишних слов, вот хорошие, плохие и раздражающие стороны Firebase, в частности Cloud Firestore.
Хорошие стороны Firebase
Firebase - это фантастика, если вы хотите создать что-то из ничего в мгновение ока, что делает ее отличной для быстрого прототипирования. Если у вас есть общая суть того, что вы хотите сделать, и вам нужен полностью настроенный бэкэнд, к которому вы можете подключиться, тогда Firebase может стать вашим помощником.
Являясь продуктом Google, это означает, что он полностью интегрирован с другими сервисами в рамках своей экосистемы. Сюда входят продукты Google Drive, в частности Google Таблицы.
В Google Таблицах у вас есть возможность создавать собственные скрипты, которые могут подключаться к вашей базе данных Firebase. Отсюда вы можете импортировать данные прямо в Firebase, полностью отформатированные на нужных уровнях и с правильным набором значений пары ключей.
Это может пригодиться, когда у вас есть набор фиктивных данных, сгенерированных из другого отдела, не связанного с разработкой, такого как финансовый, коммерческий или маркетинговый, или вам просто нужно создать что-то полностью функциональное, чтобы показать боссу в небольшом количестве время.
Это также позволяет вам делегировать свои потребности в данных кому-то другому и значительно ускорить процесс миграции наборов данных в новые приложения. Возможность изменять и обрабатывать данные в форматах, присущих отделу, также может ускорить общение и процесс понимания того, как работают данные.
Кроме того, вы можете не обладать высокими навыками в области серверных технологий или у вас не хватает времени или ресурсов для создания всей системы интеграции серверных приложений с нуля. Firebase представляет собой отличное решение, укрепляя ваши технические недостатки, чтобы вы могли сосредоточиться на обеспечении взаимодействия с пользователем с помощью своих интерфейсов.
Короче говоря, Firebase быстрая, легкая для начальной загрузки и в основном содержит интегрированные части, которые вам нужны. Это больше, чем просто база данных. Это платформа для размещения статических файлов, серверная часть микросервисов, а также готовая база данных.
Плохие стороны Firebase
Firebase отлично работает, когда вы работаете с нуля. Работа с наследием и перекрестная интеграция между разными типами проектов может быть сложным процессом.
Данные, которые вы вводите, «застревают» внутри Firebase, если вы не напишите функцию для экспорта всего набора данных. Невозможно клонировать или создавать зеркальные базы данных с теми же данными без какого-либо программного вмешательства.
Когда ваш набор данных невелик, это неплохо.
Когда ваш набор данных большой и имеет плохую структуру, клонирование базы данных может оказаться дорогостоящим занятием. Почему? Потому что Firebase взимает плату за чтение и запись. Если ваши данные не структурированы наиболее эффективным образом, это может привести к удвоению счета (один счет за чтение одной базы данных, а другой за запись в ваше зеркало-клон).
Плата только за то, что вы используете, может быть преимуществом, но при правильном использовании и использовании она также может обернуться для вашего приложения, если управление затратами не является частью вашего мыслительного процесса.
Firebase может загружаться быстро и легко, вам все равно нужно подумать о том, как будут выглядеть ваши данные и куда они будут отправляться. Нетрудно внезапно столкнуться с огромными расходами, когда запрос данных страницы приводит к 50 запросам чтения к базе данных Firebase.
Как это возможно? Представьте себе страницу корзины - у вас есть сведения о корзине, отдельные линейки продуктов, информация о пользователе, дополнительные данные, дополнительные продажи, перекрестные продажи, рекламные акции и все остальное, что вы потенциально можете разместить на странице оформления заказа. В этом списке уже перечислено семь вещей. А теперь представьте покупателя, у которого в корзину добавлено более трех товаров. Ваши требования к данным уже начинают расти.
Проблема со многими разработчиками, использующими Firebase, заключается в том, что мы склонны мыслить с менталитетом SQL при структурировании и запросах данных. Однако это может стать проблемой для вашего приложения, потому что, когда дело доходит до взимания платы на основе запросов, а не по часам, те же приложения концепций и структурирования не работают.
Раздражающие части Firebase
Когда дело доходит до Firebase, многие разработчики оказываются привязанными к сервису из-за созданных данных и кода внешнего интерфейса.
Хотя данные можно экспортировать (по цене), создание кода внешнего интерфейса, отделенного от процесса вызова и работы с Firebase, не обсуждается достаточно широко.
Это может привести к тому, что многие разработчики окажутся слишком тесно связанными с самой базой данных. Хотя Firebase упрощает загрузку чего-либо с нуля, все же необходимо заранее продумать архитектуру вашего приложения.
Честно говоря, фронтенд-архитектура нужна независимо от того, над каким проектом вы работаете. Тем не менее, многие из нас попадают в привычку делать вещи только потому, что могут. Очистка и структурирование часто являются последним портом размышлений в таких ситуациях.
Чтобы отделить базу данных Firebase от внешнего приложения, вам потребуется создать дополнительный слой, который будет отделять службы данных от пользовательского интерфейса. В большинстве случаев я просто использую переходник или мост, в зависимости от ситуации, прогнозируемых будущих требований и потенциального направления.
Взвешивая все это
В качестве заявления об отказе от ответственности я никоим образом не связан с FIrebase. Это написано с точки зрения пользователя сервиса и того, что я обнаружил за два года работы с ним для различных проектов.
Основное преимущество Firebase заключается в том, что он устраняет уровень сложности, который возникает при работе в качестве разработчика полного стека. В каком-то смысле это обман тега fullstack и делегирование основных задач по настройке серверов, бэкэндов и баз данных кому-то другому.
Это не обязательно плохо. Иногда вы просто хотите продолжить работу над интерфейсом, а не возиться с данными и писать API. Поддержка GraphQL в Firebase также упрощает жизнь благодаря единому интерфейсу и стандартизированной методологии получения данных.
Серьезное падение Firebase также служит преимуществом. Отчасти потому, что сильные и слабые стороны службы определяются тем, как ее использует разработчик. В то время как базы данных на основе SQL оплачиваются почасово, модель Firebase с оплатой по факту использования может привести к ленивым структурам данных, что приведет к экспоненциальным затратам, если ваше приложение является общедоступным и становится вирусным. Этот стартап, например, получил счет в 30 тысяч долларов за 72 часа. Никто этого не хочет.
Хотя потенциальная стоимость Firebase может показаться ошеломляющей и опасной, это не должно вас отпугивать. Скорее, он должен действовать как предостережение о том, как следить за тем, как вы структурируете свои данные.
Также следует отметить, что Firebase не является окончательным и единственным решением ваших потребностей в данных. Раньше я использовал его больше как гибридное решение с другими типами баз данных для хранения важных основных наборов данных и управления ими.
Firebase хороша для временных и постоянных данных, структура которых должна быть гибкой и изменчивой, чтобы соответствовать постоянно меняющимся требованиям.
Итак, каков окончательный вердикт Firebase по прошествии двух лет?
Он мне до сих пор нравится, даже с плохими деталями. Почему? Потому что плохими частями Firebase можно управлять, и я все еще могу напрямую влиять на его последствия и смягчать их. Есть вещи, которые Firebase делает лучше, чем SQL (для которого требуется отдельный бэкэнд для работы в качестве интерфейса), и служба поставляется с собственным набором предварительной интеграции, которая ускоряет процесс разработки.
Firebase неплохая. Хотя это не совсем идеальный сервис, он делает то, что рекламирует, - предоставляет платформу, позволяющую быстро создавать приложения, ориентированные на мобильные устройства.
