AI-конструктор с Supabase: база, вход и файлы проекта

AI-конструктор с Supabase: база, вход и файлы проекта

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

Что даёт связка с Supabase на практике?

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

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

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

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

Кто за что отвечает после подключения?

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

Как проходит подключение по шагам?

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

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

Что писать в описании, чтобы данные легли правильно?

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

Сравните. Слабо: «сделай приложение для записи клиентов с базой». Сильно: «Мастер маникюра. Клиент выбирает свободное время и оставляет имя и телефон, запись сохраняется. Мастер входит по своей почте и видит список записей на неделю, может отметить запись отменённой. Клиент видит только свою запись, чужие ему не показываются».

Во втором варианте видны роли, сущность, действие и правило доступа. Из такого описания получается работоспособная структура таблиц с первого раза. Из первого получается макет, который потом три правки доводят до смысла.

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

Каким проектам Supabase нужен, а каким нет?

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

Признак, по которому решают: появляется ли в проекте слово «мой». Мой заказ, мой прогресс, мои клиенты. Как только оно появилось, нужны учётные записи, а значит и место, где эти записи лежат.

Сколько это стоит?

Считать надо две суммы отдельно, и путать их дорого.

Free даёт 2 400 кредитов разово: этого хватит посмотреть, как устроен процесс, но не довести проект до запуска. Pro стоит $25 в месяц и даёт 20 000 кредитов, то есть примерно 16 платформ, или 33 сборки, или 66 правок. Business стоит $50 в месяц и даёт 20 000 кредитов.

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

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

Что проверяет песочница, а что остаётся на вас?

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

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

Поэтому проверка правами остаётся ручной, и делается она в два аккаунта. Заведите второго тестового пользователя, создайте запись под первым и попробуйте открыть её под вторым. Если увидели, значит правило описано неточно, и это чинится обычной правкой.

Такой же порядок работает с файлами. Загрузите документ, выйдите, зайдите под другим аккаунтом, попробуйте открыть ссылку. Ответ на этот вопрос лучше получить от себя, чем от постороннего человека через полгода.

Где проходят границы интеграции?

Три вещи стоит назвать прямо, до того как вы начнёте.

Конструктор не заменяет команду разработки на сложном продукте. Когда логики становится много и она специфичная, доводить её приходится последовательностью правок, а не одним удачным описанием. В какой-то момент дешевле забрать исходники через экспорт в GitHub и передать проект разработчику, и связка с Supabase этому не мешает: база останется той же самой.

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

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

С чего начать

Разумный порядок такой. Сначала опишите проект одной внятной формулировкой с ролями и правилом доступа, соберите первую версию и посмотрите, совпала ли структура данных с задуманной. Только после этого подключайте свой проект Supabase и переносите в него настоящие записи.

Первую сборку можно сделать на бесплатных кредитах и решить по результату, нужна ли вам внешняя база вообще. Начать удобнее всего на zugo.dev: описание в одну фразу, минута на простую сборку, несколько минут на многостраничную платформу.