Как создать сайт с базой данных и личным кабинетом без кода

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

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

Чем функциональный сайт отличается от обычной страницы

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

Функциональный сайт ведет себя по-разному в зависимости от пользователя и данных. После входа клиент видит свое имя, список заявок и текущие статусы. Администратор получает другую картину: общую очередь, контакты клиентов, фильтры и действия. Значит, проекту нужны как минимум:

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

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

Сначала данные, потом интерфейс

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

Сущности, поля и связи на простом примере

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

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

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

Для каждого поля заранее решите, обязательно ли оно, кто его заполняет и можно ли его менять. Например, клиент пишет тему и описание, но не должен сам устанавливать статус «выполнено». Администратор меняет статус, но не редактирует email владельца заявки через карточку обращения.

Что должен видеть пользователь и администратор

Составьте небольшую матрицу доступа до создания экранов. Она быстро обнаруживает неоднозначные требования.

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

Минимальная структура личного кабинета

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

Регистрация и вход

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

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

Профиль, список записей и карточка записи

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

Обязательно спроектируйте пустое состояние. Новый пользователь не должен видеть пустую белую область. Ему нужна короткая подсказка и понятное действие «Создать первую заявку». Также нужны состояния загрузки, ошибки и отсутствия доступа.

Роли и границы доступа

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

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

Как WUNA работает с базой данных

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

Встроенная база

На дату подготовки материала встроенная база доступна на платных планах «Стандарт» и «Бизнес». В документации указаны лимиты 100 МБ и 300 МБ соответственно. Условия могут измениться, поэтому перед запуском проверьте лимиты базы по тарифам и правила поведения при заполнении хранилища.

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

Подключение своей Supabase

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

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

Авторизация не заменяет правила доступа

Вход подтверждает, кто открыл приложение. Правила доступа определяют, какие строки этот человек может читать и менять. Для собственной Supabase это настраивается одновременно через права таблиц и Row Level Security. Официальная документация Supabase по RLS рекомендует включать RLS для каждой таблицы в открытой схеме, отзывать лишние права у клиентских ролей и задавать отдельные политики для разрешенных операций. Наличие формы входа или поля user_id само по себе не изолирует записи.

В клиентском приложении можно использовать publishable key или его устаревающий аналог anon, но безопасность все равно зависит от прав и RLS. Secret key и устаревший JWT-ключ service_role обходят RLS и должны оставаться только на сервере. После генерации проверьте код и переменные окружения: такие секреты не должны находиться в клиентском JavaScript, истории чата, публичном репозитории или файле, который скачивает браузер.

Промпт для сайта с базой и кабинетом

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

Создай веб-приложение для [тип бизнеса]. Главный сценарий: зарегистрированный клиент создает заявку и отслеживает ее статус в личном кабинете.

Нужны две роли: пользователь и администратор.

Данные:
1. Профиль пользователя: имя, email, телефон.
2. Заявка: номер, тема, описание, статус, дата создания, владелец.
3. Допустимые статусы: новая, в работе, выполнена, отменена.

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

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

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

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

Сборка по этапам вместо одного большого запроса

1. Каркас. Создайте экраны, меню и переходы на нейтральных тестовых данных.
2. Модель. Добавьте таблицы, обязательные поля, связи и допустимые статусы.
3. Авторизация. Настройте регистрацию, вход, выход и восстановление доступа.
4. Пользовательский путь. Свяжите создание заявки со списком и карточкой.
5. Административный путь. Добавьте список всех заявок и изменение статуса.
6. Права. Проверьте ограничения для каждой роли и прямого адреса.
7. Пограничные случаи. Обработайте пустые поля, повторную отправку, удаленную запись и недоступный ресурс.

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

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

Проверка данных, ролей и восстановления доступа

Тестировать нужно не отдельные кнопки, а законченные истории. Создайте таблицу с ожидаемым результатом и отмечайте фактическое поведение.

• Пользователь А регистрируется, подтверждает доступ, создает две записи и видит обе.
• Пользователь Б регистрируется отдельно и не видит записи пользователя А.
• Пользователь Б открывает прямую ссылку на запись пользователя А и получает отказ без раскрытия содержимого.
• Администратор видит обе учетные записи и меняет статус одной заявки.
• Пользователь А видит новый статус после повторного входа.
• После выхода защищенный запрос отклоняется. Если кнопка браузера «Назад» показывает сохраненный экран, обновление и любое действие не должны возвращать доступ к данным.
• Восстановление пароля работает для зарегистрированного адреса и не раскрывает постороннему, существует ли конкретный аккаунт.

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

Ограничения, безопасность и случаи для разработчика

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

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

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

Публикация и частые вопросы

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

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

Каждый пользователь точно увидит только свои записи?

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

Когда встроенной базы становится недостаточно?

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

Что публиковать первым?

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