Интерфейс готов. Теперь приложению нужно хранить данные, пускать пользователей и принимать файлы. Для этого не обязательно писать свой сервер.
Что на самом деле нужно приложению
Почти любое приложение с пользователями требует одного и того же:
- база данных и API к ней: создать, прочитать, изменить, удалить запись;
- вход: регистрация, пароль или вход через сервис, сброс пароля, сессии;
- права: пользователь видит свои данные и не видит чужие;
- файлы: аватарки, документы, картинки;
- обновления в реальном времени: новые сообщения, статусы заказов.
Писать всё это заново для каждого проекта долго, и ошибки здесь стоят дорого: утечка данных начинается с одного забытого условия в API.
Готовый бэкенд
Готовый бэкенд (BaaS, backend as a service) берёт эти задачи на себя. Вместо своего API приложение обращается к нему через SDK:
// данные текущего пользователя, без своего сервера
const { data } = await supabase.from("orders").select("*");
Права проверяются не в коде фронтенда, а в самом бэкенде, правилами доступа. Это ключевой момент: код фронтенда видит любой пользователь, а правила на сервере изменить нельзя.
Два самых распространённых открытых варианта: Supabase и PocketBase. Оба можно разместить на своём сервере.
Supabase
Построен на Postgres. Даёт API по таблицам, вход пользователей, файлы, realtime, функции и веб-админку.
- Плюсы: полноценный SQL, расширения (поиск по эмбеддингам, геоданные, задачи по расписанию), большое сообщество, совместимость с любым инструментом для Postgres.
- Минусы: около 13 сервисов, от 4 GB памяти для self-hosted версии.
- Права: политики RLS в Postgres.
PocketBase
Один исполняемый файл с базой SQLite.
- Плюсы: запускается за минуту, потребляет десятки мегабайт памяти, понятная админка.
- Минусы: один сервер, ограничение на параллельную запись, версия до 1.0.
- Права: правила на каждую операцию с коллекцией.
Свой API
Классический вариант: бэкенд на FastAPI, Django, NestJS, Laravel плюс Postgres.
- Плюсы: любая логика, любые интеграции, полный контроль.
- Минусы: вход, права, загрузку файлов и realtime придётся писать или собирать из библиотек.
Как выбрать
| Ситуация | Выбор |
|---|---|
| Прототип, внутренний инструмент, мобильное приложение, мало ресурсов | PocketBase |
| Продукт с ростом данных, нужен SQL, приложение сгенерировано Lovable или Bolt | Supabase |
| Сложная бизнес-логика, интеграции с платёжками и 1С, команда бэкендеров | свой API |
| Не уверены | Supabase: из него проще всего уйти, это обычный Postgres |
Варианты совмещаются. Частая схема: Supabase для данных и входа плюс небольшой сервис для вебхуков платёжной системы и тяжёлых задач.
Главная ловушка: права доступа
Почти все утечки в приложениях на готовом бэкенде происходят по одной причине: правила доступа не настроены.
В Supabase таблица, созданная SQL-запросом без включения RLS, доступна через API любому, у кого есть ключ anon. А ключ anon лежит в коде фронтенда, его видит каждый. Для каждой таблицы нужно включить RLS и описать политику:
alter table orders enable row level security;
create policy "свои заказы"
on orders for select
using (auth.uid() = user_id);
В PocketBase новые коллекции по умолчанию закрыты. Опасность в обратном: правило открывают пустой строкой «чтобы заработало», и коллекция становится публичной.
Ключи администратора (service_role в Supabase, токен суперпользователя в PocketBase) обходят все правила. Им место только на сервере, никогда во фронтенде и не в репозитории.
Чек-лист перед запуском
- У каждой таблицы или коллекции настроены правила, проверено под двумя разными пользователями.
- В коде фронтенда нет ключей администратора.
- Настроен SMTP: без него не придут письма подтверждения и сброса пароля.
- Включён бэкап базы и проверено восстановление.
- Данные пользователей из России хранятся на серверах в России (152-ФЗ).