Можно ли построить популярное приложение на Firebase: опыт Headway

В каких случаях стоит выбирать Firebase для построения бэкенда мобильного или веб-приложения, с какими сложностями придется столкнуться и действительно ли Firebase поможет сэкономить время?

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

Но так было не всегда. В начале 2019 в идею поверили ребята из Genesis R & D, и команда из трех человек начала работать над продуктом. Жесткие, но выполнимые условия инвесторов требовали показать прибыль за короткий срок. Запускаться нужно было ASAP. Мы считаем, что использование сервисов Firebase было одним из ключевых решений, которые позволили построить успешный продукт.

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

Наши задачи на старте проекта

На старте стояла задача за два месяца собрать команду и опубликовать Headway в магазин приложений. Чтобы запустить MVP, нам были нужны:

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

Времени на поиск DevOps и развертывание инфраструктуры вне облака не было. Мы принялись искать решение. Выбирали между инфраструктурой на AWS или Google. Остановились на Google Firebase.

Что такое Firebase

Firebase — это backend as a service. А конкретно — платформа, которая содержит в себе большой набор инструментов, широко используемых в мобильных и веб-приложениях. Firebase позволяет полностью «сдаться облаку» и не тратить время на развертывание и поддержку API, базы данных, файлового хранилища, сервисов аналитики, авторизации пользователей и др. Firebase тесно связана с Google Cloud: если бэкенд-разработчику чего-то не хватает в первой платформе, то, скорее всего, это можно сделать через вторую.

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

Вендор-лок может убить бизнес в один момент. К примеру, поставщик может сменить условия лицензионного соглашения и ваш сервис потеряет возможность использовать продукт. Мигрировать будет больно.

Нужно время на обучение работе с новыми продуктами. И может, например, оказаться, что нужный продукту функционал на 90% доступен «из коробки», но оставшиеся 10% реализовать будет сложно и дорого из-за ограничений поставщика.

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

Время поджимало, и решение было нужно принимать быстро. Перспектива сразу получить пачку готовых решений все же выглядела заманчиво. Рискнули. Это же стартап — здесь много рисков 🙂

База данных

Выбор между Firestore и Realtime Database

Firebase предлагает выбрать базу данных NoSQL, исходя из потребностей будущего приложения. Мы выбрали Cloud Firestore как более функциональную, хорошо масштабируемую базу данных.

В условиях нехватки ресурсов ключевым преимуществом стала возможность клиентов (мобильных и веб-приложений) работать с базой данных напрямую через sdk вместо нашего собственного API. Мобильное приложение может самостоятельно зарегистрировать пользователя, записать данные о нем в базу данных, загрузить аватар в хранилище и даже принять оплату. Не нужно тратить время бекенд разработчиков на CRUD-операции с базой.

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

Бэкапы в Firestore вызывают боль.Если забэкапить всю базу целиком, то и восстановить ее можно будет только целиком (прощайте пользовательские данные со времени последнего бэкапа). Если же бэкапить коллекции по одной, то важно не забывать добавлять имена новых коллекций в скрипт бэкапа.

Стоимость

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

Мониторинг

Чтобы вовремя замечать проблемы, мы настроили алерты. Мой предыдущий опыт был только с self-hosted-проектами, поэтому я был очень рад, когда узнал, насколько просто настраиваются алерты в Firebase.

Но однажды мы получили алерт о резком росте количества чтений из базы. Тогда участникам технической команды пришлось угадывать, что пошло не так и у кого, ведь, кроме количества чтений, информации на графиках немного. Хотелось бы знать, какой клиент (Android? iOS? Backend?) какую коллекцию читает, но нет — такая информация в Google Cloud Monitoring для Firestore не собирается.

Безопасность Firestore

В Firestore есть Security Rules, которые позволяют гибко настраивать ограничения доступа к данным. Правила интегрированы с Firebase Auth, благодаря чему можно ограничивать доступ на уровне документов или коллекций. Таким образом можно легко настроить права пользователя на запись только в свой документ, разрешить чтение общедоступного контента и запретить любое взаимодействие с другими данными в базе.

С помощью Security Rules можно даже настроить rate limiting. Правда таким способом защититься от DDoS не выйдет, потому что чтение из базы данных при выполнении правила стоит денег, даже если запрос в результате отклонен.

Сейчас мы хотим спрятать Firestore за прокси, но решение еще не в продакшене.

API через Cloud Functions

На старте проекта хотелось сконцентрироваться на написании приложения, вместо того чтобы разворачивать инфраструктуру для API. Решили делать API на Cloud Functions. Продукт предлагает заманчивые возможности:

• автоматическое масштабирование
• инструменты мониторинга и логирования
• тесная интеграция с другими продуктами Google Cloud
• набор готовых типовых решений

Триггерами для функции могут быть HTTP-запрос, сообщение в очереди Pub/Sub, изменение данных в Firestore, Auth или Storage. Сейчас мы используем почти все возможные. Когда админка загружает картинку, в Storage вызывается функция, чтобы сжать и сохранить эту картинку в нескольких размерах. Google Play Market шлет уведомления о покупках в Pub/Sub. На эти сообщения реагирует функция.

Можно использовать все возможности Google Cloud вместе с Firebase. Однажды платежный шлюз изменил правила доступа к API: разрешил доступ только по white-листу. У нас все общение со шлюзом построено на Firebase Functions. Функции мигрируют между серверами Google. Добавлять в white-лист все диапазоны IP-адресов Google — идея так себе. Для функций настроили Cloud VPC. Прикрепили к VPC публичный IP-адрес и пустили трафик функций обработки платежей через VPC.

Firestore не умеет выполнять сложные запросы. К примеру, такой запрос уже не отработает:

citiesRef.where("state", ">=", "CA").where("population", ">", 100000);

Чтобы решить проблему, вызывается cloud-функция по изменению коллекции в Firestore. Изменение документа пользователя дублируется в MongoDB. Из MongoDB делать сложные выборки уже не проблема.

Рефакторинг структуры документов в Firestore вызывает проблемы. Проходить скриптом по коллекции с миллионами документов и пересохранять их в новой структуре может быть долго и дорого. Приходится учить программы работать с несколькими возможными структурами документов. Это зло:

if (user.platform === constants.iOS || user.appData.platform === constants.iOS) {

    // ...

}

Стабильность

За два года работы Headway Firebase у нас ложился два раза минут на 30. Потом чинился. Время простоя соответствует SLA.

Выводы

Выбирать Firebase как бэкенд-платформу для приложения в ряде случаев можно:

• если нужно быстро запустить мобильное или веб приложение за короткий срок
• если структура данных не содержит множества связей и хорошо ложится на NoSQL модель
• если запросы в базу будут несложными

Но чем сложнее становится продукт, тем сильнее чувствуются и ограничения Firebase. Мы готовы будем мигрировать, если потребуется.