Вы попросили нейросеть создать веб-приложение. Через несколько минут появились страницы, кнопки, личный кабинет и аккуратный интерфейс. Можно открыть сайт и показать его знакомым. Но при попытке зарегистрировать пользователя, сохранить запись или подключить оплату выясняется, что часть функций только изображает работу.
Это обычная граница между демонстрацией идеи и приложением, которым можно пользоваться. ИИ помогает быстро получить код, но наличие кода ещё не означает, что все части системы соединены между собой. Разберём, с чего начать, чтобы превратить такой результат в работающий сервис.
Сначала выясните, что действительно работает
Возьмём пример AI-чата. Нейросеть создала окно переписки, поле ввода и кнопку отправки. На экране даже появляются ответы. Но если посмотреть код, может оказаться, что ответы заранее записаны в массиве, а история сообщений исчезает после перезагрузки страницы.
Внешне приложение выглядит готовым. Фактически у него пока есть только интерфейс. Проверка начинается с действий пользователя. Откройте приложение в новом браузере, отправьте сообщение, обновите страницу и попробуйте повторить действие. Посмотрите, какие данные сохранились и откуда пришёл ответ. Для каждой основной функции нужно определить, выполняет ли она настоящее действие или показывает заранее подготовленный результат.
Разделите интерфейс и серверную работу
Допустим, пользователь нажал кнопку «Отправить». В работающем AI-чате это запускает цепочку действий.
- Интерфейс принимает сообщение и показывает состояние загрузки.
- Сервер получает запрос и проверяет входные данные.
- Сервер обращается к API языковой модели, используя свой секретный ключ.
- Результат возвращается в интерфейс, а при необходимости сохраняется в истории пользователя.
Если сгенерированное приложение выполняет только первый пункт, нужно доделать остальные. Просто добавить ещё одну кнопку или красивую анимацию недостаточно.
Для такого разделения подходят Next.js на стороне интерфейса и Django REST Framework на стороне backend. Но стек сам по себе не решает задачу. Нужно понимать, какие действия выполняются в браузере, какие на сервере и где хранятся данные.
Подключите одну настоящую функцию
Не нужно переносить весь проект на новую архитектуру за один раз. Выберите одно действие, от которого зависит смысл приложения. Для AI-чата это отправка сообщения и получение ответа модели. Предположим, backend уже предоставляет endpoint /api/chat/. Клиент может обратиться к нему так:
async function sendMessage(message: string) {
const response = await fetch("/api/chat/", {
method: "POST",
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({ message }),
});
if (!response.ok) {
throw new Error("Не удалось получить ответ");
}
return response.json();
}
/api/chat/ обозначает маршрут, доступный на том же домене, что и приложение. Это может быть собственный серверный обработчик Next.js или маршрут, который перенаправляет запрос к Django. Если Django размещён отдельно, адрес и способ обращения нужно настроить для конкретной архитектуры. Функция показывает границу между интерфейсом и API. Она отправляет данные и проверяет HTTP-ответ. Но сама по себе не создаёт backend, не подтверждает личность пользователя и не защищает приложение от лишних запросов.
На сервере потребуется реализовать обработку сообщения, подключение к модели и правила доступа. API-ключ модели остаётся на backend, а не передаётся в браузер.
Решите, какие данные должны сохраняться
Следующий вопрос появляется после перезагрузки страницы. Должен ли пользователь увидеть предыдущий диалог? Если да, где приложение будет хранить сообщения? Для короткой демонстрации можно держать историю в памяти браузера. Но такая история не привязана к учётной записи и может пропасть. Когда нужен личный кабинет и работа с нескольких устройств, данные обычно хранят в базе на сервере.
На этом этапе можно описать несколько сущностей. Например, пользователь, чат и сообщение. У сообщения есть текст, время создания и ссылка на конкретный чат. У чата есть владелец. Такое описание помогает понять, какие данные принадлежат одному пользователю и почему нельзя отдавать чужую переписку по произвольному идентификатору. Для постоянного хранения понадобится база данных, а для личных записей ещё и серверная проверка доступа.
Проверьте вход и права пользователя
Нередко ИИ создаёт форму входа, которая меняет состояние интерфейса, но не проверяет учётные данные на сервере. После нажатия кнопки появляется аватар и надпись «Вы вошли». Это ещё не авторизация. В работающем приложении сервер должен определить пользователя и проверять его права при обращении к защищённым данным. Спрятать кнопку в интерфейсе недостаточно. Например, при запросе истории диалога backend проверяет, принадлежит ли чат текущему пользователю. Даже если кто-то вручную изменит адрес запроса, сервер не должен отдавать чужие сообщения.
Один из вариантов построения такой схемы разобран в статье «Как устроена JWT-авторизация и почему API перестаёт пускать пользователя».
Проверьте работу за пределами своего компьютера
Когда интерфейс и сервер уже обмениваются данными, возникает следующая задача. Приложение должно запускаться не только в режиме разработки. Соберите проект, настройте переменные окружения на хостинге и проверьте публичный адрес. Отдельно убедитесь, что браузер обращается к действующему API, а сервер видит необходимые ключи и подключается к базе.
После публикации повторите основной пользовательский путь. Создайте новую учётную запись, выполните действие, обновите страницу и проверьте сохранённые данные. Не ограничивайтесь открытием главной. Если приложение зависит от внешней модели, проверьте поведение при её недоступности. Пользователь должен получить понятное сообщение об ошибке, а интерфейс не должен бесконечно показывать загрузку.
Что делать дальше
Когда одна функция проходит весь путь от интерфейса до сервера и обратно, остальные можно подключать по той же схеме. Появляются общие правила обработки ошибок, хранения данных, авторизации и развертывания.
В моей статье на Habr о платном AI-микро-SaaS разобрано, как такие части складываются в сервис, который выходит за пределы демонстрационного проекта.
Посмотрите AI-Chat. Это пример приложения, где интерфейс Next.js связан с Django API и языковыми моделями.
Курс «AI на Django и Next II» посвящён серверной части AI-приложения, авторизации, работе с API и запуску проекта. Он не учит генерировать сайт одной командой, а помогает разобраться в устройстве системы, которую предстоит поддерживать.
Сгенерированный интерфейс может стать хорошим началом. Дальше стоит выбрать одну реальную задачу пользователя и провести её через все необходимые части приложения, от нажатия кнопки до сохранённого результата.