Supabase для вайбкодинга: база данных, авторизация и файлы без отдельного бэкенда

Интерфейс прототипа готов: форма принимает заявку, кнопка меняет состояние, список выглядит убедительно. Но после обновления страницы всё пропадает. Следующий запрос к ИИ обычно звучит так: «Добавь базу данных, регистрацию и загрузку файлов». В этот момент проекту уже нужен не ещё один экран, а понятная серверная часть.

Supabase позволяет собрать её из готовых компонентов. У каждого проекта есть полноценная база PostgreSQL. По схеме базы сервис автоматически формирует Data API, через который приложение читает и изменяет строки. Рядом работают авторизация пользователей и хранилище файлов. Поэтому для личного кабинета, каталога, внутреннего инструмента или первой версии сервиса не обязательно с нуля писать сервер с маршрутами для каждой таблицы.

Фраза «без отдельного бэкенда» здесь требует оговорки. Серверная ответственность не исчезает. В ограниченном сценарии браузер или мобильное приложение может обращаться к Data API напрямую, но только если доступ к данным закрыт политиками Row Level Security, или RLS. Действия с секретными ключами, платежами, административными правами и внешними сервисами всё равно должны выполняться в доверенной среде: на вашем сервере или в серверной функции.

Для первого проекта достаточно различать четыре компонента.

База данных остаётся центром этой схемы. Auth выдаёт приложению сведения о вошедшем пользователе. Политики RLS сопоставляют этого пользователя со строками в таблицах. Storage хранит сами файлы, а в базе обычно остаются их пути и связанные записи. У хранилища есть собственные правила доступа: разрешение читать строку в таблице не даёт автоматически разрешение скачать файл.

В простой двухуровневой схеме клиент обращается к Supabase напрямую:

интерфейс → Data API / Auth / Storage → база и файлы

Так можно устроить, например, кабинет, где каждый пользователь создаёт заявки и видит только свои. Публичный ключ проекта находится в клиенте, а реальные границы доступа задаёт RLS. Само присутствие такого ключа в коде не должно открывать чужие данные.

В трёхуровневой схеме между интерфейсом и Supabase появляется доверенный серверный слой:

интерфейс → ваш сервер или Edge Function → Supabase и внешние сервисы

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

Поэтому Supabase лучше воспринимать не как способ «убрать бэкенд», а как готовую основу для данных, пользователей и файлов. Она сокращает объём инфраструктуры, но архитектурные решения всё равно остаются за вами. Дальше разберём один маршрут целиком: от таблицы заявки до проверки, что один пользователь не видит данные другого.

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

До создания таблиц запишите четыре действия обычными словами:

• вошедший пользователь создаёт заявку;

• видит список только своих заявок;

• может открыть одну свою заявку;

• при необходимости прикрепляет к ней файл.

Не начинайте с универсальной схемы «на будущее». Для первой версии достаточно таблицы requests с идентификатором заявки, идентификатором автора, темой, описанием, статусом и временем создания. Если статус меняет только сотрудник, обычному пользователю не нужен прямой доступ к обновлению всей строки.

Таблицу можно создать через Table Editor или SQL Editor. Важен не способ, а связь: поле автора должно однозначно указывать на пользователя из Auth. Тогда правило доступа можно выразить без догадок: пользователь работает со строкой, только если её user_id совпадает с идентификатором текущей сессии.

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

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

Для таблицы заявок понадобятся как минимум такие правила:

• читать можно строки со своим user_id;

• вставлять можно строку только со своим user_id;

• обновлять свои строки можно, только если такая операция вообще нужна пользователю;

• удаление либо описывается отдельно, либо не разрешается.

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

Если таблица создаётся в Dashboard, RLS обычно включается по умолчанию. Для таблиц, созданных через SQL или другой инструмент, это нужно проверить явно. Пока RLS выключен, публичная схема через Data API может оказаться доступнее, чем вы рассчитывали.

Клиенту нужен publishable key, чтобы обратиться к проекту. Этот ключ рассчитан на использование в публичном приложении. Безопасность строк обеспечивают не попытки спрятать его в собранном JavaScript, а авторизация и политики RLS.

Secret key и прежний service_role устроены иначе: они дают повышенный доступ и обходят RLS. Их нельзя добавлять в браузерное приложение, мобильную сборку, публичный репозиторий или текст запроса к ИИ. Такой ключ допустим только в доверенном серверном окружении.

Если заявке нужен документ, создайте bucket и определите правила для объектов. У Storage свой контроль доступа. Политика таблицы requests не распространяется на файл автоматически.

Практичная схема выглядит так: сам файл лежит в Storage, а в базе хранится путь к объекту и связь с заявкой. В пути можно использовать идентификатор пользователя и заявки, но путь не заменяет политику. Правила должны отдельно проверять, кто загружает, читает и удаляет объект. Также заранее ограничьте допустимые типы и размеры файлов на уровне продукта.

Проверка должна доказывать не только успешный сценарий, но и запреты. Создайте две тестовые учётные записи A и B и пройдите ожидаемые состояния:

1. A создаёт заявку и видит её после перезагрузки.

2. B не получает эту заявку в списке и не может открыть её по известному идентификатору.

3. Пользователь без сессии не читает закрытые данные.

4. A не может подменить автора заявки или изменить запрещённое поле.

5. B не может скачать файл A, даже если узнал путь.

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

В этом маршруте уже встретились схема данных, авторизация, работа с кодом и безопасность. В полном цикле к ним добавятся Git, деплой и серверные функции. Если эти части приходится собирать по разрозненным подсказкам, в программе курса «Вайбкодинг на максималках» они выстроены последовательно: от Git, GitHub, Codex и VS Code до базы данных, сервера, функций с нейросетями и защиты проекта. Курс не отменяет проверку политик, но помогает видеть всю систему, а не только очередной сгенерированный файл.

Переносить всю логику в клиент только ради простой схемы не стоит. Если операция использует закрытый ключ стороннего сервиса, повышенные права или административное решение, ей нужен доверенный серверный слой. Это может быть ваш сервер или Edge Function. Браузер передаёт ему допустимые входные данные, а секреты и привилегированные действия остаются внутри.

Типичные примеры такой границы:

• подтверждение платежа по сообщению платёжной системы;

• выдача роли сотрудника или администратора;

• массовое изменение чужих записей;

• отправка письма через сервис с секретным ключом;

• обращение к модели по закрытому API-ключу;

• операция из нескольких шагов, которую нельзя оставлять наполовину выполненной.

Если ИИ предлагает «для простоты» положить secret key в переменную фронтенда, это не упрощение, а перенос секрета в публичную сборку. Название переменной и файл .env не защищают значение, если сборщик добавляет его в код браузера.

Права пользователей: только одна часть готовности. Перед публикацией пройдите ещё несколько пунктов.

Резервное копирование. Бэкапы базы Supabase не включают сами объекты Storage. Записи о файлах и пути могут сохраниться, а содержимое bucket в них не входит. Для важных документов нужен отдельный план копирования и восстановления. Проверять следует не наличие слова «backup» в панели, а возможность вернуть и строки, и файлы.

Схема данных. Добавляйте обязательные поля, уникальность и связи там, где правило действительно относится к данным. Интерфейс может ошибиться или быть обойдён. База должна отвергать состояние, которое продукт считает невозможным.

Ошибки интерфейса. Различайте отсутствие данных, запрет доступа, потерю сети и внутреннюю ошибку. Пустой экран не объясняет, сработала политика RLS или запрос вообще не дошёл до сервиса.

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

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

Supabase особенно удобен, когда первая версия опирается на связанные данные, пользовательские сессии и файлы, а команда хочет быстро получить рабочую серверную основу. Он не избавляет от проектирования схемы и прав, зато делает их видимыми: таблицы лежат в PostgreSQL, доступ к строкам выражен политиками, а клиент работает через готовый API.

Начните не с переноса всего проекта, а с одного вертикального сценария. Выберите функцию, где пользователь создаёт запись и затем читает её. Опишите допустимые действия, настройте RLS, проверьте запреты второй учётной записью и только после этого добавляйте файлы или серверные операции.

Критерий успеха здесь простой: не «ИИ подключил Supabase без ошибок», а конкретный пользователь может выполнить нужное действие, посторонний не получает доступ, а вы понимаете, где лежат данные, ключи и резервные копии. Тогда сервис действительно сокращает путь до продукта, не скрывая его архитектуру.