Backend для мобильного приложения: Firebase, Supabase или свой сервер

За что отвечает серверная часть

Мобильное приложение показывает интерфейс, а сервер определяет, какие данные считать верными: кто вошел, что ему доступно, какой заказ оплачен, какая подписка действует, какие уведомления уже отправлены и что может изменить администратор.

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

Firebase, Supabase или собственное решение

Firebase Authentication предоставляет готовые средства входа и восстановления аккаунта. Архитектура Supabase строится вокруг Postgres, авторизации, автоматически создаваемых API, файлов и функций. Эти возможности экономят время, но не отменяют проектирование прав, бизнес-правил и защиты данных.

Собственное решение не всегда лучше. Оно оправдано, когда готовый сервис плохо вмещает бизнес-процессы: выплаты продавцам, нестандартное ценообразование, строгий аудит действий, сложные интеграции или особые требования к хранению данных.

Что сильнее всего влияет на стоимость

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

Админ-панель — часть продукта

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

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

Платежи и доступ

После оплаты сервер должен проверить результат, обновить доступ, сохранить историю и помочь поддержке разобраться в спорной ситуации. Для подписок также важны продление, отмена, истечение срока, возврат и восстановление покупки. Подробнее об этом — в статье о разработке приложения с подпиской.

Чек-лист перед оценкой

1. Какие роли есть у пользователей, сотрудников и партнеров?
2. Какие данные создает и изменяет каждая роль?
3. Кто может просматривать, редактировать, подтверждать и удалять записи?
4. Какие платежи, подписки, возвраты и выплаты нужны?
5. С какими сервисами нужно связать приложение?
6. Чем команда должна управлять через админ-панель?
7. Какие уведомления отправляются и при каких условиях?
8. Какие события нужны для аналитики?
9. Какие данные чувствительны и как долго их хранить?
10. Кто следит за ошибками, резервными копиями и обновлениями?

Типичные ошибки

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

Как Appfyl работает с серверной частью

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

Команда Appfyl выпустила более 100 мобильных и веб-продуктов, включая AB.Money, CakeSchool, My Cake и Padi Pay. Примеры можно посмотреть в портфолио Appfyl.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Следующий шаг

Перед выбором Firebase, Supabase или собственного решения выпишите роли, объекты данных, права, интеграции и действия админ-панели. После этого технический выбор и оценка становятся гораздо точнее.

Частые вопросы