Есть красивый frontend — что делать дальше, чтобы получился работающий продукт

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

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

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

Запишите для каждого шага наблюдаемый результат. После регистрации пользователь получает сессию сразу либо после подтверждения контакта — это зависит от настройки Auth. После создания проекта появилась запись с владельцем. После загрузки файл доступен тому же пользователю. После повторного входа состояние восстановилось. Такой список превращает разговор о «готовности» в проверяемые утверждения.

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

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

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

Браузер показывает состояние и отправляет запросы. Сервер проверяет входные данные, личность, права доступа и выполняет операции, которым нельзя доверять на клиенте. MDN описывает этот обмен как запрос клиента и ответ сервера; серверная часть получает данные из базы, проверяет их и формирует результат.

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

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

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

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

Supabase предоставляет полноценную базу Postgres; Auth, Storage, Realtime и Edge Functions строятся вокруг неё. Это ускоряет сборку, но не отменяет проектирование таблиц, миграций и прав.

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

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

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

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

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

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

GitHub Actions позволяет запускать сборку, линтеры, проверки безопасности и функциональные тесты при изменениях в репозитории. Зелёный CI означает только то, что выбранные проверки прошли на конкретной версии кода. Он не доказывает правильность требований, работу production или отсутствие всех уязвимостей.

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

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

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

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

Данные исчезают после перезагрузки. Проверьте, завершилась ли серверная операция, что вернул API и читает ли экран запись из базы, а не только локальное состояние браузера.

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

Файл загрузился, но позже не открывается. Проверьте bucket, путь объекта, владельца, политику чтения, срок подписанной ссылки и наличие объекта в плане резервного копирования.

Кнопка создаёт дубли. Заблокируйте повторную отправку в интерфейсе, но также добавьте серверную идемпотентность или ограничение уникальности там, где повтор опасен.

Всё работает локально, а после выпуска нет. Сравните переменные среды, миграции, домен, TLS, разрешённые redirect URL, CORS, доступ к внешним сервисам и идентичность развернутой версии. Не чините наугад: сначала найдите различие между средами.

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

Кандидат можно считать готовым к ограниченному запуску, когда:

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

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

Если вы только закончили интерфейс, возьмите один сценарий и оформите его как таблицу «действие → данные → право → серверная операция → ошибка → проверка». Затем доведите этот путь до повторного входа и теста вторым пользователем. После этого масштабируйте готовый образец.

Чтобы отдельно проверить воспроизводимую сборку и критерий работающего результата, используйте статью «Как установить Hermes Agent на VPS и получить работающего личного ИИ-агента».

На воркшопе «Человек 2.0» Codex + Hermes этот переход выполняют на своём проекте: от требований и frontend до базы, пользователей, личного кабинета, заявок, профилей, заказов, админки и CRM. Посмотреть программу воркшопа.

• MDN — Client–server overview: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview
• Supabase — Database: https://supabase.com/docs/guides/database/overview
• Supabase — Auth: https://supabase.com/docs/guides/auth
• Supabase — Storage: https://supabase.com/docs/guides/storage
• Supabase — Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
• OWASP — Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
• GitHub Docs — Continuous integration: https://docs.github.com/en/actions/get-started/continuous-integration
• web.dev — Web Vitals: https://web.dev/articles/vitals
• Человек 2.0 — программа воркшопа Codex + Hermes: https://human20.app/launch/workshop
• Материал и ссылки проверены 11 сентября 2026 года. Технический TTL — 30 дней.