Сервис записи к мастеру: что делают фронтенд, Python-бэкенд и фуллстек-разработчик

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

Чтобы запись состоялась, несколько частей сайта должны работать вместе. Страница показывает выбор и принимает сведения Лены. Программа сайта проверяет расписание и сохраняет визит. Затем страница сообщает подтверждённый результат. Разберём эту последовательность и увидим, как в ней различаются задачи фронтенд-, бэкенд- и фуллстек-разработчика.

Для примера возьмём вымышленную парикмахерскую с одним мастером Анной и одной услугой длительностью час. В расписании 20 октября 2026 года есть два заранее подготовленных интервала: 14:00–15:00 и 15:00–16:00. Часы показаны по местному времени студии. Оплату, перенос и отмену пока не включаем: сначала разберём одну надёжно работающую запись.

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

Эта часть работает в браузере и называется фронтендом. Разработчик задаёт содержимое страницы, оформление и поведение. HTML помогает описать элементы, CSS — их внешний вид, JavaScript — действия: выбор времени, отправку формы и показ ответа. Названия разные, но задача общая — помочь Лене выполнить нужное действие и понять его результат.

При этом важно разделить два сообщения. «Выбрано 14:00» означает только выбор в браузере. «Вы записаны» появится после того, как программа сайта подтвердит сохранение. Пока этого не случилось, страница должна показывать выбранное время, но ещё не подтверждать запись.

Создавать такие страницы и управлять их поведением вы научитесь на курсе «Frontend-разработчик» от Skillfactory. В нём разбирают HTML, CSS, JavaScript и TypeScript, формы, работу с сервером и ошибки. Для нашей записи эти навыки помогают показать Лене выбранный час, объяснить, что заявка ещё обрабатывается, и предложить следующее действие при отказе.

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

Когда Лена отправляет форму, браузер передаёт её сведения серверу — компьютеру, на котором работает программа сайта. Эта программа принимает решения по правилам парикмахерской. Её называют бэкендом, или серверной частью. Браузер показывает результат, а бэкенд выясняет, можно ли действительно записать человека.

Чтобы части понимали друг друга, разработчики договариваются о передаваемых данных и ответах. Такой способ обмена называют API. Для нашего случая нужно передать выбранный интервал, имя и контакт. В ответ может прийти подтверждение, сообщение о занятом времени либо объяснение проблемы с полем. Общий путь обмена рассматривает обзор MDN.

У интервалов есть внутренние обозначения: S1400 для 14:00 и S1500 для 15:00. Они нужны программе, чтобы выбрать именно подготовленную строку расписания. Лена продолжает видеть обычные часы. Браузеру не приходится самому вычислять продолжительность визита и объявлять свободным новый час, которого в расписании нет.

Сервер проверяет заявку и сохраняет её в базе данных — организованном хранилище записей. Допустим, визит Лены получил номер B104. После подтверждения сохранения сервер передаёт номер, мастера, дату и время обратно браузеру. Теперь страница может честно сообщить: Лена записана к Анне на 14:00.

Номер визита и обозначение интервала решают разные задачи. B104 — конкретная запись клиента, S1400 — час в расписании. Их связь позволяет позже узнать, какой визит занял это время. Сведения сохраняются в базе и не должны исчезать после перезапуска программы.

Для нашего бэкенда выберем Python. Обработку обращений можно построить с помощью Django — готового набора инструментов для сайтов. Он помогает принимать запросы и работать с данными, но не знает правил Анны сам по себе. Разработчику нужно объяснить, кому и на какое время разрешено записываться.

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

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

Проверять эти правила и сохранять данные вы сможете научиться на курсе «Python-разработчик» от Skillfactory. Программа включает основы Python, базы данных, тестирование, Flask, Django и обмен между приложениями. Для сервиса записи это помогает соединить получение заявки с проверкой расписания и достоверным ответом человеку.

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

Вернёмся к началу этой записи и представим, что вместе с Леной на тот же час записывается Олег. Оба открыли страницу, пока 14:00 ещё было свободно, выбрали его и отправили форму. Если программа только посмотрит «свободно», а затем сохранит визит без дополнительного правила, две почти одновременные проверки могут получить одинаковый ответ.

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

Допустим, первой сохранилась заявка Лены и получила B104. Для Олега сервер возвращает сообщение о занятом времени. Фронтенд обновляет расписание и предлагает ему 15:00. Введённые имя и контакт остаются в форме: повторять их из-за другого клиента незачем.

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

Связанные изменения также нужно сохранять согласованно: либо все необходимые записи появились, либо при ошибке частичный результат отменён. Такую группу действий называют транзакцией; её устройство объясняет документация Django. Но сама транзакция не заменяет правило «один визит на интервал». В нашем примере эти условия решают разные задачи.

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

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

В этот момент неверно писать «Запись не создана»: программа могла уже завершить работу. Неопределённость между выполненной операцией и потерянным ответом разбирается в инженерном материале Stripe. Для нашего сайта нужно продумать повтор так, чтобы он помог получить результат, а не создавал ещё один визит.

Поэтому перед первой отправкой заявка получает отдельное обозначение — ключ операции. В статье назовём его R72. Это не номер визита и не новый час: это способ узнать повтор той же попытки. Сервер связывает R72 с принятыми сведениями и результатом B104.

Если первая обработка закончилась, повтор с тем же обозначением и теми же сведениями возвращает уже созданную запись B104. Второго визита не появляется. Если же с R72 пришёл другой интервал или контакт, программа не должна молча считать их прежней заявкой. Такое несовпадение нужно обработать отдельно.

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

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

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

Особенно полезно такое понимание на сбоях. Например, сервер правильно сообщает Олегу о занятом времени, а страница при любом ответе показывает «Готово». База защищена от второй записи, но человек всё равно введён в заблуждение. Фуллстек-разработчик может проследить сообщение через обе части и исправить их связь.

Соединять поведение страницы с серверной логикой вы научитесь на курсе «Fullstack-разработчик на Python» от Skillfactory. В программе объединены JavaScript, Python, Django и работа с базами данных. Эти навыки помогают пройти весь путь от выбора часа до сохранённого визита и проверить, что каждый ответ правильно понят на экране.

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

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

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

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

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

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

Затем проверьте несколько связанных случаев:

Для каждого случая важно сопоставить экран и данные. Подтверждение на странице должно соответствовать сохранённому визиту. Если визит есть в базе, но Лена не получила дату и время, она всё ещё не знает, когда приходить. Сервис должен выполнить обе части задачи.

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

Не добавляйте сообщение «Письмо отправлено», пока уведомления не сделаны и не проверены. Для нашей версии достаточно достоверной записи и номера. Лена должна знать, к кому и когда придёт, а разработчик — объяснить, почему Олег не получит тот же час.

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

Создавать страницы и поведение в браузере вы сможете научиться на курсе «Frontend-разработчик». Серверную разработку на Python — на курсе «Python-разработчик». Работу с обеими частями и их связью — на курсе «Fullstack-разработчик на Python».