Firebase или свой бэкенд: что выбрать для мобильного приложения

Firebase или свой бэкенд — выбор между скоростью старта и контролем. Firebase и другие сервисы класса backend as a service дают готовые авторизацию, базу, хранение файлов, push и аналитику: для MVP это недели экономии. Свой сервер нужен, когда приложение должно обмениваться данными с 1С и CRM, работать по сложным правилам и ролям или хранить персональные данные на серверах в Казахстане. На практике чаще всего выигрывает гибрид: готовые сервисы там, где они дешевле, и свой API для бизнес-логики и интеграций.

Firebase или свой сервер: сравнение по восьми параметрам

Таблица показывает, что это не «хорошее против плохого», а два инструмента для разных стадий и задач. Ошибка — выбирать по привычке команды, а не по требованиям продукта.

Firebase: плюсы и минусы для бизнес-приложения

Отдельный вопрос — хранение персональных данных. Законодательство Казахстана предъявляет требования к месту хранения персональных данных граждан, и для многих компаний это решающий аргумент в пользу своего сервера или облака в Казахстане. Требования меняются, поэтому сверяйте актуальную редакцию закона и внутренние политики безопасности на дату запуска.

Backend as a service: когда это правильный выбор

Готовые сервисы идеальны для MVP. Задача первой версии — проверить гипотезу на реальных пользователях за 8–10 недель, а не построить инфраструктуру на годы. Поэтому в нашей разработке MVP авторизация, push, платежи, чат, карты и аналитика подключаются через Firebase и готовые SDK, а не пишутся с нуля. Это недели экономии, и именно за счёт этого бюджет первой версии примерно вдвое меньше полного приложения.

BaaS подходит и для продуктов, которые живут сами по себе: контентные приложения, сервисы записи без связки с учётной системой, внутренние инструменты небольшой команды. Если приложению не нужно ежедневно сверять остатки с 1С и передавать сделки в CRM, свой сервер может оказаться избыточным.

Важное условие: даже на Firebase мы проектируем архитектуру так, чтобы готовый сервис можно было заменить своим позже, когда продукт докажет спрос. Бюджет MVP по составу работ мы разобрали в статье «Сколько стоит MVP приложения».

Свой сервер для приложения: когда без него не обойтись

Собственный бэкенд нужен там, где приложение — часть бизнес-процесса, а не отдельный продукт. Типичные признаки:

• Обмен с 1С. Номенклатура, остатки по складам, цены и типы цен, заказы, статусы, договоры и акты. Остатки и цены — по расписанию от 15 минут, заказы — сразу.
• События в CRM. Установка, регистрация, заявка, покупка, брошенная корзина — в карточку клиента amoCRM или Битрикс24 с источником, обратно — статусы и push клиенту.
• Единый профиль с сайтом. Клиент входит одинаково на сайте и в приложении, корзина и история общие.
• Платежи и документы. Kaspi, Halyk, Freedom Pay, ЭДО — с отражением в учёте.
• Требования к хранению. Данные на ваших серверах или в облаке в Казахстане, шифрование, роли, аудит.

Всё это — работа интеграции приложения с сайтом, CRM и 1С: от 1 500 000 ₸ за связку с CRM и аналитикой, от 3 000 000 ₸ за полный контур с единым профилем, 1С и платежами. Бэкенд пишем на Laravel или Node.js, API документируем, а при сбое одной из систем данные копятся в очереди и не теряются.

ПРАВИЛО

Если источник правды о клиентах, заказах и остатках — ваша 1С и CRM, бэкенд приложения должен быть вашим.

Стоимость на росте: где BaaS становится дороже

На старте Firebase почти бесплатен: лимиты рассчитаны на небольшие проекты. Тарификация идёт за операции чтения и записи, хранение и трафик, поэтому расходы растут вместе с активностью пользователей. Для MVP это плюс — платите по факту. Для зрелого продукта с ежедневными синхронизациями каталога, частыми обновлениями статусов и тысячами активных пользователей счёт становится заметным и плохо прогнозируется.

У своего сервера логика обратная: есть разработка и постоянный хостинг с первого дня, зато расходы растут ступенчато и предсказуемо. Хостинг бэкенда размещается в вашем аккаунте и оплачивается по тарифу провайдера. Подробнее о том, из чего складывается серверная часть и её содержание, — в статье «Сколько стоит бэкенд для мобильного приложения».

Гибрид: готовые сервисы плюс свой API

Чаще всего мы не выбираем одно из двух. Бизнес-логика, данные клиентов и интеграции живут на своём API, а готовые сервисы закрывают то, что дешевле не писать:

• push-уведомления через Firebase Cloud Messaging и APNs — инициируются событиями в вашем бэкенде, CRM или биллинге;
• отчёты о падениях и аналитика событий;
• карты, чат, SMS — через готовые SDK провайдеров.

Так вы получаете скорость готовых решений там, где она не несёт рисков, и контроль там, где лежат деньги и данные клиентов. Если со временем какой-то готовый сервис станет дорогим или неудобным, его можно заменить, не трогая остальную систему: приложение работает с вашим API, а не напрямую с поставщиком.

Как перейти с Firebase на свой бэкенд без потери пользователей

1. АудитНеделя на разбор текущей схемы данных, правил доступа и облачных функций: что переносим, что оставляем на готовых сервисах.
2. Свой API рядомНовый бэкенд запускается параллельно, данные синхронизируются. API версионируем: новые методы появляются рядом со старыми.
3. Перенос пользователейАккаунты объединяем по номеру телефона или почте, дубли разбираем по согласованным правилам.
4. Постепенный переводНовая версия приложения работает с новым API, старые версии продолжают работать, пока ими пользуются. Старый канал отключаем по плану, когда новый отработал без ошибок.

Как выбрать за один разговор

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