Фронтенд показывает форму, бэкенд принимает и проверяет заявку, база данных хранит запись. Сообщение «Отправлено» имеет смысл, когда вы знаете, на каком шаге оно появляется.
ИИ быстро собирает красивую форму. Но где окажется заявка после нажатия кнопки — в почте, в базе или только на экране? Пройдём этот путь на учебной мастерской. Незнакомое объяснение можно разобрать с помощником в Ное; ниже есть отдельная инструкция для такого разговора.
Коротко
- Фронтенд — часть приложения для пользователя. Бэкенд — программа на сервере, которая выполняет его запросы.
- API задаёт способ общения между частями: куда обратиться, что передать и какой ответ ждать.
- В нашем опыте обновление страницы сохранило заявку в памяти сервера. Перезапуск самого сервера её потерял.
- С локальной базой SQLite та же заявка пережила перезапуск. При намеренном отказе сохранения форма честно показала ошибку.
Что делает каждая часть приложения
В учебной мастерской посетитель вводит имя и нажимает «Оставить заявку». Он взаимодействует с фронтендом, от английского frontend: видит поля, кнопку и сообщение о результате. В этой статье речь о веб-приложении, поэтому эта часть работает в браузере.
Нажатие запускает запрос к бэкенду, от backend, — программе на сервере. Она читает присланное имя, проверяет его и решает, можно ли сохранить заявку. Затем возвращает ответ. Связь браузера и сервера подробнее разобрана в первом уроке серии.
База данных хранит записи так, чтобы программа могла добавлять их, находить и изменять. В нашей учебной базе у заявки два поля: идентификатор и имя. Идентификатор помогает отличить эту запись от остальных.
Фронтенд, бэкенд и база — разные роли. Они не обязательно находятся на трёх отдельных компьютерах. Учебный сервер и база у нас работали на одном. На большом сайте устройство может быть сложнее, но вопрос остаётся тем же: кто показывает, кто обрабатывает, кто хранит?
В обзоре клиент-серверного обмена MDN показано, как серверная программа получает данные и возвращает результат браузеру. Из внешнего вида формы это устройство не узнать: два одинаковых экрана могут сохранять заявки совершенно по-разному.
Как части договариваются об отправке
API — Application Programming Interface, программный интерфейс, — описывает, как одна программа обращается к другой. Для нашей формы договор простой: отправить запрос на /api/requests, передать поле full_name, получить подтверждение или ошибку.
full_name переводится как «полное имя». Это имя поля в данных; посетителю его запоминать не нужно. Важно, чтобы обе стороны использовали одинаковое имя. Если форма отправит name, а сервер ищет full_name, он не получит ожидаемые данные. Эту поломку разберём в уроке о поиске ошибки с ИИ.
POST — название действия в HTTP: в нашем случае передать данные для создания заявки. HTTP — Hypertext Transfer Protocol, протокол передачи гипертекста, — задаёт обмен запросами и ответами. Для чтения списка заявок мы используем другое действие — GET, получить данные.
Данные передаются в JSON — JavaScript Object Notation, текстовом формате записи данных. Он встречается во многих языках, несмотря на JavaScript в названии. В учебной отправке это одна пара «название поля — значение»:
{"full_name":"Учебная Анна"}
Сервер проверяет имя, сохраняет запись и отвечает кодом 201 Created — «создано». В ответе есть идентификатор заявки. После этого фронтенд показывает «Заявка сохранена» с этим идентификатором. Всё это мы проверили настоящим запуском, используя вымышленное имя.
Почему «Отправлено» ещё нужно связать с сохранением
Надпись в браузере может появиться в любой момент: сразу после клика, после получения ответа или после подтверждённого сохранения. Её смысл задаёт код приложения. Поэтому просите помощника показать условие, при котором она появляется.
В нашем варианте подтверждение возвращается после записи. Мы отдельно запросили список заявок и нашли там тот же идентификатор. Это второе наблюдение: не только ответ «создано», но и чтение сохранённого результата.
Потом намеренно включили отказ учебного хранилища. Сервер ответил 503, то есть сообщил о недоступности. Форма показала «Не сохранено: Учебное хранилище недоступно». Новая запись не появилась, прежняя осталась на месте.
Тут легко ошибиться в самом коде страницы. Встроенный в браузер способ отправки запросов fetch не считает любой ответ с ошибкой разрывом соединения. Код ошибки нужно проверить отдельно. Это поведение описано в руководстве MDN по Fetch. Если проверять только факт получения ответа, можно показать человеку ложное «Успешно».
При этом сохранение заявки не подтверждает отправку письма или сообщения сотруднику. Если такие шаги нужны, их тоже нужно наблюдать. В учебном проекте уведомлений нет: здесь прослеживаем только запись и её чтение.
Куда исчезла заявка после перезапуска
Сначала мы хранили заявки в обычном списке внутри работающей программы. Его удобно быстро написать, но содержимое существует, пока живёт этот процесс. Процесс — запущенная программа со своим текущим состоянием.
Отправили заявку «Учебной Анны» и обновили страницу. Запись осталась. Это ожидаемо: браузер заново открыл сайт, но серверная программа продолжала работать с тем же списком.
Затем остановили и заново запустили именно учебный сервер. Список стал пустым. Программа начала работу заново, а сохранять список в файл мы её ещё не научили.
Во втором варианте подключили SQLite, небольшую базу данных, которую приложение может использовать без отдельного сервера базы. В этом опыте она хранила записи в файле. Документация Python показывает такой способ работы с SQLite.
Повторили отправку, перезапустили серверную программу и прочитали список. Заявка сохранилась с тем же идентификатором. Мы не удаляли файл базы между запусками.
Вывод этого опыта узкий и полезный: обновление вкладки не проверяет сохранность после перезапуска сервера. А файловая база помогает только пока доступен её файл. Если при выкладке временный диск стирается, наличие слова SQLite в проекте ещё не решает проблему. Где живут данные вашего приложения, нужно выяснить отдельно.
Если к заявке нужно добавить телефон или другое поле, меняется и устройство хранения. В уроке про миграции базы данных добавляем поле к уже существующим заявкам и проверяем, что осталось от старых записей.
Когда путь заявки уже понятен, можно собрать полную картину сервиса. В уроке про архитектуру проекта связываем правила, базу, файлы и фоновые задачи, а затем разбираем отказ почты и повтор действия.
Почему браузеру нельзя доверять всю проверку
Поле required может попросить посетителя заполнить имя. Но к серверу можно обратиться и другим способом, минуя эту форму. Поэтому бэкенд тоже проверяет присланные данные.
Мы отправили пустое имя напрямую в учебный сервер. Он вернул 422: формат запроса прочитан, но ожидаемого непустого имени в нём нет. Дополнительная запись не появилась.
Похожим образом сервер должен решать, что человеку разрешено. Например, посетитель может попросить чужую заявку, просто изменив адрес запроса. Скрытая кнопка на фронтенде не мешает ему это сделать. Права нужно проверять там, где запрос исполняется. В нашем маленьком опыте входа в аккаунт и личных кабинетов нет — для их устройства нужен отдельный разбор.
Когда ИИ предлагает «проверку на клиенте», уточните: есть ли такая же нужная проверка на сервере? Клиентом здесь называется браузерная сторона приложения. Это слово описывает участника обмена, не покупателя услуги.
Как попросить ИИ проследить вашу заявку
Скопируйте запрос в помощника, который уже работает с файлами проекта. Подставьте одну конкретную форму. Начните с чтения и объяснения; запуск проверки на рабочем сайте с реальными клиентами для этой задачи не нужен.
Помоги понять путь одной заявки в этом проекте. Я учусь разбираться в программировании.
Форма или страница: [название и путь].
Ожидаемое место заявки: [база, почта или пока неизвестно].
1. Найди поле, обработчик кнопки, запрос к серверу и код, который его принимает. Покажи точные файлы и связь между ними. Если какой-то части нет, назови это прямо.
2. Объясни, какие данные передаются, кто проверяет их и в какой момент интерфейс показывает успех. Все новые термины объясни рядом с действием.
3. Найди место хранения. Это память процесса, файл, браузерное хранилище или отдельная база? Приведи свидетельство из кода и настроек. Не выдавай предположение за факт.
4. Предложи проверку с вымышленной заявкой в отдельном локальном запуске: отправка → чтение записи → обновление страницы → перезапуск только учебного сервера → повторное чтение. Если безопасный запуск невозможен, объясни, чего не хватает.
5. Проверь план для отказа сохранения: что увидит человек и как убедиться, что приложение не показывает ложный успех. Рабочие базы, серверы и доступы не меняй.
6. Выведи карту пути заявки и один следующий шаг, который поможет понять ещё неизвестную часть. Код пока не исправляй.
Если вы только собираете первый сайт, студия Нои подходит для начала с прототипа. В задаче помощнику сразу назовите нужный результат: где должна храниться заявка и как вы её найдёте. Это конкретнее, чем просто «сделай рабочую форму».
Как проверить объяснение помощника обычным разговором
Иногда ИИ выдаёт уверенный отчёт: «Форма работает, данные сохраняются». Текстовый помощник может помочь заметить, чего в отчёте не хватает. Для этого не отправляйте ему данные реальных посетителей — замените их вымышленными.
Ты помогаешь начинающему понять путь заявки: фронтенд, бэкенд, API и хранение данных. Объясняй термины через действия из присланного примера. Работай только с текстом пользователя; доступа к его проекту, базе и серверу у тебя нет.
Вводные:
Что делает форма: [описание].
Что сообщил ИИ-помощник или разработчик: [обезличенный отчёт].
Что действительно наблюдали: [запрос, ответ, чтение записи, обновление страницы или перезапуск].
1. Построй короткий путь заявки из известных шагов. У каждого напиши, есть ли подтверждение. Не достраивай отсутствующую базу или уведомление по догадке.
2. Отдельно объясни разницу между обновлением вкладки и перезапуском серверной программы. Не объявляй сохранность после второго доказанной проверкой первого.
3. Проверь, что известно про момент сообщения «Успешно», сохранение записи и обработку отказа. Не считай один код ответа доказательством всех последующих действий.
4. Если данных недостаточно, задай до двух точных вопросов. Предложи один опыт с вымышленными данными в отдельной учебной среде, без рабочих баз и клиентов.
5. Оформи ответ: «Путь заявки», «Что подтверждено», «Что проверить дальше». Не заявляй, что ты сам отправил запрос, перезапустил программу или нашёл запись.
Ответ не длиннее 1200 знаков, без вложенных списков и повторных пересказов. Если после перезапуска запись не найдена, это ещё не доказывает отсутствие её в любом хранилище: может не работать чтение. Не придумывай способ загрузки страницы и код без наблюдения.
Создайте в Ное помощника для разбора формы и поставьте ему эту инструкцию. Он поможет разбирать обезличенные отчёты о вашем проекте и формулировать вопросы к разработке. Проверку сохранения вы делаете в самом приложении: переписка с помощником её не заменяет.
На пробе с обновлением вкладки помощник верно заметил, что сохранность после перезапуска ещё не проверена. Но в другом ответе добавил сообщение «успешно», которого мы ему не присылали. Поэтому сравнивайте его пересказ с наблюдениями: подробный ответ тоже может содержать лишнюю догадку.
С чего начать прямо сейчас
Возьмите одну форму. Попросите помощника показать строку кода, после которой посетитель видит успех, и место, где хранится заявка. Затем найдите одну учебную запись по её идентификатору.
Про выпуск новой версии читайте в уроке о CI/CD и деплое. А если данные пропадают после восстановления из копии, пригодится отдельный разбор проверки резервных копий.
Частые вопросы
JavaScript бывает только во фронтенде?
Нет. На нём можно писать и серверную программу, например для среды Node.js. По одному названию языка нельзя понять, где выполняется код. Смотрите, кто его запускает: браузер или серверная среда.
У любого сайта есть база данных?
Нет. Страница с расписанием может быть обычным файлом. Даже форма иногда отправляет письмо без собственной базы. Важно понять нужный путь именно вашего проекта, а не добавлять все части ради правильной схемы.
Данные в браузере переживут перезапуск сервера?
Они могут сохраниться в браузере, но это ещё не запись на сервере. На другом устройстве их может не быть. Уточните, где именно хранится результат и кто должен иметь к нему доступ.
SQLite подходит только для учебных примеров?
Её применяют и в настоящих приложениях. Наш опыт не выбирает базу для всех задач: он показывает различие памяти процесса и сохранения в файле. Для выбора важны нагрузка, способ запуска и требования к данным.
Нужно ли перезапускать рабочий сервер, чтобы проверить форму?
Для первого знакомства достаточно отдельного учебного запуска. Перезапуск живого сервиса может затронуть посетителей. Сначала разберите устройство и подготовьте проверку там, где нет клиентских данных и действующих заказов.
Вывод
Проследите одну запись до места хранения и прочитайте её оттуда. Это простое действие даст больше понимания формы, чем уверенное «всё готово» в ответе ИИ.
