Firebase от Google – отличное бессерверное решение для разработчиков и компаний. Вообще говоря, мой первый опыт в облаках связан именно с ней. Я тогда писал на Android и только что запустил свой стартап. У меня не было денег на то, чтобы нанять себе в помощь разработчиков, которые занимались бы бэкендом. По этой причине я (и двое моих друзей) искали максимально простое решение для бэкенда. Так я узнал про Firebase.
Firebase представлялся одним из наилучших вариантов в нише «бэкенд как сервис». Освоить ее было очень легко – мне хватило пары дней, чтобы разобраться и начать применять ее в проекте. Изначально мы ставили цель подготовить прототип, посмотреть, как его примут на рынке и собрать побольше отзывов от пользователей.
Однако мы приняли ошибочное решение и продолжили использовать Firebase и в коммерческой версии продукта. Ниже я расскажу, как это ударило по проекту.
Почему выбор пал на Firebase
Как я уже сказал, основной причиной, по которой мы выбрали Firebase, стала ее простота. Но было и другое серьезное основание для такого решения. Мы делали приложение, в котором нужно было устанавливать связь между двумя сторонами в реальном времени. Это деловое предложение имело для нас очень большой вес, и поэтому Firebase напрашивалась как самый удачный вариант.
Есть и еще одна причина, по которой Firebase пользуется популярностью у стартапов – ей можно пользоваться бесплатно. Пока не наберешь некоторое количество пользователей, за сервис можно в буквальном смысле ничего не платить. Firebase сэкономила мне не только приличную сумму, но и массу времени – по крайней мере, так мне казалось. В денежном эквиваленте, отказавшись от найма еще одного разработчика, за шесть месяцев я сэкономил около десяти тысяч долларов.
Также у Firebase очень богатый функционал для аутентификации. Нам нужно было авторизовать пользователей по телефону, и с этим сервисом всё получалось очень просто. Более того, за месяц аутентификацию можно провести бесплатно десять тысяч раз. Для стартапа этого достаточно. Наконец, всего несколькими строками кода можно интегрировать авторизацию через Facebook, Twitter, GitHub, Apple или Gmail.
Firebase Realtime Database – это просто магия какая-то. Сначала мы пользовались Firebase Realtime Database, потом перешли на Cloud Firestore. С точки зрения хранения данных, Cloud Firestore выигрывает у Firebase Realtime Database. Мне понравилось работать с базой данных NoSQL – быстро и масштабировать легко. А Cloud Firestore показалась мне удобнее благодаря системе хранения документов в коллекциях. Самым приятным было то, что о масштабировании можно не беспокоиться – Firebase берет это на себя.
Бесплатных предложений для разработчиков в этом плане у сервиса тоже достаточно: бесплатное чтение доступно в пределах пятидесяти тысяч операций в день, бесплатная запись – в пределах двадцати тысяч.
Как начались проблемы
Преимущества преимуществами, но спустя полгода мы стали сталкиваться и с неприятными сторонами. Это произошло, когда мы попытались добавить функциональности и расширить сервис, чтобы охватить растущую аудиторию.
Проблема первая: запросы
Чтобы дополнить функционал, нам нужно было усложнять запросы. Но в Cloud Firestore много ограничений в том, что касается запросов и фильтрации данных. С простыми операциями проблем не возникает, но вот провести сложный запрос – та еще головоломка.
Здесь важно понимать: это не SQL. Так что нам пришлось создавать дополнительные коллекции и чаще дублировать данные, чтобы сложные запросы можно было свести к простым. Дублирование, в свою очередь, повлекло за собой новые сложности: приходилось после любых изменений обновлять 5-6 коллекций.
Проблема вторая: нет устойчивого бэкенда
Смысл Firebase в том, чтобы создать бессерверную среду, поэтому, само собой, это исключает наличие бэкенда в том виде, в каком он существует в других системах. В отсутствие бэкенда мы обращались к базе данных напрямую из приложения. Это оказалось огромной ошибкой. Такой прямой способ чтения и записи данных вызвал множество проблем.
Был и другой способ получать доступ к данным, его мы тоже испробовали. Мы использовали облачную функцию Firebase, чтобы создавать API. Но производительность у таких API не та, что у нормальных. Там есть свои ограничения, которые делают их меленными и неудобными для разработчиков.
Проблема третья: падения
По-настоящему трудно стало тогда, когда команда увеличилась в размерах. Каждому разработчику необходимо было ясно понимать, как устроена база данных и каковы принципы ее работы.
Чтение и запись данных осуществлялись напрямую, и из-за этого много времени у нас пропадало впустую. Учитывая, что мы решили разрабатывать сразу для трех платформ (Android, iOS и веб), схема работы с записью прямо в базу данных оказалась крайне непрактичной. Стоило кому-то отправить данные в неверном формате, и всё сразу падало на трёх платформах. Производительность всей команды стала ощутимо проседать.
Проблема четвертая: правила безопасности
Безопасность – важный аспект для любого IT-продукта. В Firebase предусмотрены специальные инструменты для обеспечения безопасности. Так как фреймворк позволяет читать и записывать данные со стороны фронтенда, там внедрена система записи «правил безопасности» через панель администрирования. Мне это кажется очень неудобным. Прописывать правила безопасности в API гораздо проще.
*
Наконец, спустя десять месяцев, мы приняли решение отказаться от Firebase. На данный момент мы используем сервис только для авторизации, уведомлений и кое-какой аналитики.
Каждую проблему, с которой мы столкнулись при работе с Firebase, можно было решить, и некоторые из них мы создали для себя сами из-за собственных просчетов. Но решение становились всё сложнее и сложнее, и это стало напрягать. Непонятно, какие еще трудности нам пришлось бы улаживать в будущем.
Исходя из этого, мы решили уйти с Firebase, хотя это было очень непросто. Не буду вдаваться в детали, скажу только, что пришлось выстраивать заново большую часть системы. Перестройка стоила нам значительных потерь, но это еще не самое страшное. Хуже всего, что пришлось поступиться самым ценным ресурсом – временем. Кроме того, при переходе с одной технологии на другую мы потеряли и сколько-то пользователей.
Поэтому я призываю всех: если хотите воспользоваться Firebase Cloud Firestore или Realtime Database, тщательно всё спланируйте. Эти сервисы оптимальны, если вам нужно что-то создать очень быстро или вы пока работаете над прототипом.
Если платформа у вас будет только одна, можно рассматривать Firebase (Android, либо iOS, либо веб) как вариант. Если же продукт нужно представить на нескольких платформах, это чревато серьезной головной болью.
Если сложных запросов в проекте не предвидится, то всё в порядке. В противном случае лучше не связывайтесь. Для крупных проектов брать Firebase тоже не стоит, в перспективе вы наживете массу неприятностей. А вот для небольших мобильных приложений этот сервис в самый раз. Я сейчас сам над таким работаю и отдал предпочтение Firebase, потому что проект не масштабный, будет разрабатываться на Flutter и не потребует никаких сложных запросов. Так что соотношение цены и качества выходит приемлемое.
Думаю, у Firebase большое будущее, однако облачные функции неизбежно придется совершенствовать и дополнять новыми возможностями. Сейчас она – хорошее орудие в хороших руках. Не зная, как с ней работать, можно самому себе навредить.
Прежде чем составлять стек технологий, очень важно ознакомиться со всеми их сильными и слабыми сторонами, как я показал вам сегодня на собственном опыте. У Firebase хватает и тех, и других. Пожалуйста, соберите как можно больше информации, прежде чем делать выбор в его пользу. Я до сих пор жалею, что не изучил решение подробнее, прежде чем внедрять в проект. Мог бы избежать лишних трат времени и денег.
А как складывался ваш опыт работы с Firebase?
