Приложение в Lovable с базой данных: как собрать с нуля

Одна из самых частых ошибок у новичка выглядит так: открыть Lovable, написать что-то вроде «сделай мне сервис как Notion, только лучше», получить красивый интерфейс, а потом застрять на самом неприятном месте. Где хранить данные, как пускать пользователей в аккаунт, как разделить права, почему после деплоя половина не работает.

Если говорить честно, приложение в Lovable с базой данных почти никогда не ломается на кнопках и карточках. Оно ломается на структуре. Не на «красиво сделать», а на «что именно хранить, кто это видит и по каким правилам страница открывается». Ниже покажу нормальный путь, без магии и без иллюзии, что ИИ всё угадает с первого раза.

Материал рассчитан на продвинутого новичка: вы не обязаны быть разработчиком, но должны быть готовы немного думать про таблицы, роли и логику доступа. Если вы только входите в тему, сначала полезно пройтись по статье вайбкодинг: с чего начать новичку без знания кода. А перед первым промтом удобно собрать структуру через генератор ТЗ, чтобы не просить у ИИ «сделай всё».

Что мы вообще собираем

В этой схеме у нас есть три слоя:

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

Если коротко, Lovable отвечает за то, что видит пользователь, а Supabase за то, что лежит «под капотом». Связка Lovable Supabase авторизация удобна тем, что не нужно отдельно поднимать свой сервер для простого MVP. Но это не значит, что можно вообще не думать о модели данных. Как раз наоборот: чем раньше вы продумаете структуру, тем меньше потом будет хаоса.

С чего начать: не с дизайна, а со структуры

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

Минимум, который надо решить до генерации

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

Допустим, вы делаете простой сервис заявок. Тогда структура может быть такой:

users: пользователи;
profiles: профиль пользователя с ролью;
requests: заявки;
comments: комментарии к заявке;
statuses: статусы заявок, если нужна отдельная таблица.

Вот здесь обычно и происходит первая развилка. Новичок пишет слишком расплывчато.

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

Лучше: создай веб-приложение для работы с заявками. Нужны страницы: главная, вход, регистрация, кабинет пользователя, список заявок, страница одной заявки, админ-панель. Пользователь может создать и редактировать только свои заявки. Админ видит все заявки и может менять статус. Используй Supabase для хранения данных и авторизации.

Чем конкретнее постановка, тем меньше Lovable будет додумывать за вас странные вещи.

Как спроектировать базу данных в Supabase без лишней боли

Supabase часто воспринимают как «базу, которую просто подключили». На деле это центр приложения. Если структура таблиц кривая, интерфейс потом будет всё время бороться с последствиями.

Базовый набор таблиц

Для большинства стартовых проектов хватает такой логики:

Таблица	Что хранит	Что важно не забыть
auth.users	Учётные записи авторизации	Её создаёт Supabase Auth, руками обычно не трогаем
profiles	Имя, роль, служебные поля пользователя	Связать с auth.users по user_id
items или requests	Основные записи приложения	Добавить owner_id, created_at, status
comments	Комментарии к записям	Связать и с записью, и с автором

Почему не стоит хранить роль прямо «где-нибудь в интерфейсе»? Потому что роль должна жить в базе и проверяться на уровне доступа. Иначе пользователь сможет открыть DevTools, подменить что-то на клиенте и увидеть больше, чем надо.

Какие поля нужны почти всегда

id: уникальный идентификатор;
created_at: дата создания;
updated_at: дата обновления, если запись редактируется;
owner_id или user_id: кто создал запись;
status: если у сущности есть этапы;
title, name, description: в зависимости от задачи.

Не плодите поля «на всякий случай». Лишнее потом мешает не меньше, чем недостающее.

Как настроить авторизацию и не запутаться в ролях

В большинстве случаев вам нужна обычная схема:

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

Supabase умеет авторизацию из коробки. Но есть важный момент: авторизация и роли не одно и то же.

Авторизация

Это ответ на вопрос: человек вообще вошёл в систему или нет.

Роль

Это ответ на вопрос: что именно он может делать после входа.

Простейшая схема ролей:

user: видит и редактирует только свои данные;
admin: видит все записи, может менять статусы, удалять или модерировать.

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

Где хранить роли

Рабочий вариант для старта: хранить роль в таблице profiles, связанной с пользователем. После регистрации создаётся профиль, где есть поле role.

Здесь у новичка часто появляется опасная мысль: «А можно просто скрыть кнопку админки, и этого хватит?» Нет. Скрыть кнопку полезно для интерфейса, но доступа это не ограничивает. Ограничение должно работать на уровне базы, через политики доступа в Supabase.

Почему без политик доступа приложение быстро становится дырявым

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

Вот базовые правила, которые обычно нужны:

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

Это тот участок, где приложение в Lovable с базой данных перестаёт быть «игрушкой для демо» и начинает быть настоящим сервисом. Даже если проект маленький, не пропускайте этот шаг.

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

Какие страницы нужны в первом рабочем варианте

Я бы не советовал сразу генерировать десять экранов. Для первого нормального релиза хватает вот такого каркаса:

Главная страница.
Страница входа.
Страница регистрации.
Личный кабинет.
Список сущностей, например заявок или задач.
Страница создания записи.
Страница просмотра или редактирования одной записи.
Админская страница, если есть роль admin.

Как их разделить по доступу

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

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

Как ставить задачу Lovable, чтобы он не собрал кашу

Самый полезный принцип тут простой: просите не «приложение целиком», а первый рабочий каркас.

Хороший запрос: создай структуру веб-приложения на Lovable с подключением к Supabase. Нужны страницы: home, sign in, sign up, dashboard, requests list, request detail, admin panel. Используй аутентификацию через Supabase Auth. Таблицы: profiles, requests, comments. У profiles есть role. Обычный пользователь видит только свои requests, админ видит все. Нужны формы создания и редактирования заявки, защита приватных страниц и базовая навигация.

Такой промт не идеален, но он уже задаёт каркас. Дальше вы идёте итерациями:

сначала страницы и маршруты;
потом подключение Supabase;
потом таблицы и связи;
потом формы и вывод данных;
потом роли и ограничения;
потом шлифовка интерфейса.

Если вы сначала просите красивый UI, а потом пытаетесь вживить в него роли, статусы и фильтры, работа становится вдвое тяжелее.

Пошаговый сценарий сборки

Шаг 1: описываем сущности и роли

На листке, в заметках, в генераторе ТЗ, неважно где. Важно, чтобы у вас был короткий документ:

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

Для подготовки первого описания удобно использовать генератор ТЗ. Не как волшебную кнопку, а как способ не забыть половину логики.

Шаг 2: создаём проект в Supabase

На этом этапе вам нужны:

новый проект;
настроенная аутентификация;
таблицы;
минимальные политики доступа;
ключи подключения проекта.

Не пытайтесь сразу делать сложные SQL-конструкции. Для первого MVP вам важнее правильные связи и доступы, чем «идеальная архитектура на вырост».

Шаг 3: создаём проект в Lovable и подключаем Supabase

Дальше просите Lovable собрать каркас страниц и подключить проект к Supabase. После подключения проверьте три вещи:

регистрация реально создаёт пользователя;
после входа открываются приватные страницы;
данные читаются и записываются в нужные таблицы.

Шаг 4: настраиваем маршруты и защиту страниц

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

Шаг 5: собираем CRUD

CRUD простыми словами: создать, прочитать, изменить, удалить запись. Для большинства мини-сервисов это и есть основа продукта.

Начинайте с минимального сценария:

создать запись;
вывести список записей;
открыть одну запись;
отредактировать;
удалить, если это правда нужно.

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

Шаг 6: добавляем роли

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

Шаг 7: проверяем после деплоя

Очень частая ловушка: в редакторе всё работает, после публикации нет. Причины обычно скучные:

не те переменные окружения;
неподключённый проект Supabase;
ошибка в redirect URL для авторизации;
другие домены, не добавленные в настройки;
политики доступа, которые в реальном сценарии режут нужный запрос.

Как деплоить без сюрпризов

Сам деплой технически часто занимает меньше времени, чем проверка после него. Перед публикацией держите короткий чек-лист.

Что проверить	Зачем
URL проекта и redirect settings	Чтобы вход и выход не ломались на боевом домене
Переменные окружения	Чтобы фронтенд видел нужный Supabase-проект
Политики доступа	Чтобы пользователь видел только то, что ему положено
Роли в profiles	Чтобы админка не была доступна всем подряд
Ошибки форм	Чтобы запись не «исчезала молча» при сбое

Если после деплоя не работает авторизация, сначала смотрите не в интерфейс, а в настройки URL и сессию. Очень часто проблема не в кнопке «Войти», а в том, что окружение не совпадает с тем, что вы тестировали локально или внутри конструктора.

Какие тесты сделать вручную перед первым запуском

Вот набор тестов, который реально спасает от глупых косяков:

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

Не тестируйте только «счастливый путь», когда всё должно работать. Тестируйте и плохие сценарии:

неверный пароль;
пустая форма;
чужой ID в URL;
пользователь без роли admin пытается открыть админку;
удалённая или несуществующая запись.

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

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

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

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

Рабочий минимальный план на один вечер

Если не хотите утонуть в деталях, сделайте так:

Опишите одну сущность, например заявки или заметки.
Оставьте только две роли: user и admin.
Создайте в Supabase таблицы profiles и requests.
Настройте регистрацию и вход.
Сделайте в Lovable страницы: home, sign in, sign up, dashboard, requests.
Добавьте создание и вывод записей.
Проверьте, что user видит только свои записи.
Добавьте отдельный экран для admin.
Опубликуйте и пройдите ручной тест по чек-листу выше.

Если хотите превратить это в первый реальный проект, откройте генератор ТЗ и соберите короткое описание своей версии приложения: сущности, роли, страницы, доступы. Потом уже отдавайте это Lovable, а не абстрактную мечту про «умный сервис с личным кабинетом».

Вопрос-ответ

Можно ли сделать приложение в Lovable с базой данных без знания кода?
Да, базовый MVP собрать можно, если речь о простом сервисе с понятной логикой. Но без понимания структуры данных, ролей и проверок доступа всё быстро превращается в хаос.

Зачем для Lovable подключать именно Supabase?
Потому что Supabase закрывает сразу несколько задач: хранение данных, авторизация пользователей и правила доступа. Для первого веб-приложения это удобная связка, когда не хочется отдельно поднимать серверную часть.

Чем отличается авторизация от ролей?
Авторизация отвечает за вход в систему: пользователь вошёл или нет. Роли отвечают за права после входа: что он может смотреть, создавать, менять и удалять.

Можно ли ограничиться скрытием кнопки для обычного пользователя?
Нет. Скрытая кнопка делает интерфейс чище, но не защищает данные. Ограничения должны работать и на уровне базы данных через политики доступа.

Какие страницы нужны в первом варианте приложения?
Обычно хватает главной, входа, регистрации, личного кабинета, списка записей, страницы одной записи и админки, если есть роль admin. Этого достаточно, чтобы собрать рабочий каркас без лишней сложности.

Что проверить после деплоя в первую очередь?
Проверьте вход и регистрацию, работу приватных страниц, redirect URL, переменные окружения и доступ к данным под разными ролями. Часто проблема после публикации не в интерфейсе, а в настройках окружения.

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

Если Lovable собрал странную структуру, что делать?
Не пытаться чинить всё сразу в интерфейсе. Лучше заново уточнить ТЗ: какие таблицы нужны, какие роли есть, какие страницы публичные, а какие приватные. Чем яснее описание, тем меньше случайных решений со стороны ИИ.