Сайт состоит из трёх частей. Фронтенд — то, что посетитель видит и нажимает в браузере; бэкенд — программа на сервере, которая принимает запросы, проверяет данные и решает, что ответить; база данных — хранилище товаров, заявок и пользователей. Простая визитка может обходиться без бэкенда и базы. Всему, что должно «помнить» данные, — каталогу, личному кабинету, админке — нужны место для хранения и серверная логика, но писать их с нуля не обязательно: их дают BaaS-платформы вроде Supabase или Firebase и внешние сервисы по API, а настройки одного посетителя можно хранить прямо в браузере.
После материала вы сможете
- описать путь одного запроса: от ввода адреса и DNS до ответа сервера и сборки страницы в браузере
- объяснить, за что отвечают фронтенд, бэкенд и база данных и почему проверки цен и прав выполняются на бэкенде
- отличить статичный сайт от динамического и определить, нужны ли сайту бэкенд и база данных
- проверить по чек-листу, что репозиторий, хостинг, база данных, админка и домен принадлежат компании
Содержание
Аналогия: сайт устроен как ресторан
Представьте ресторан. Зал с меню, столами и вывеской — это фронтенд: всё, что видит гость. Кухня, куда гость не заходит, — это бэкенд: там принимают заказ, проверяют, есть ли продукты, и готовят блюдо. Склад и холодильники — база данных: там хранится всё, из чего готовят. Официант, который носит заказы между залом и кухней, — это запрос, который браузер отправляет на сервер.
- 01Браузер
- 02Сервер
- 03База данных
Путь одного запроса: что происходит после клика
Браузер и сервер общаются по протоколу HTTP: браузер отправляет запрос, сервер возвращает ответ. Так описывает устройство веба документация MDN — справочник разработчиков, который поддерживает Mozilla. Вот как это выглядит по шагам, когда вы открываете страницу каталога:
Вы вводите адрес или жмёте ссылку
Браузер сначала узнаёт, на каком сервере живёт сайт: по доменному имени через DNS он получает IP-адрес — номер компьютера в сети.
Браузер отправляет запрос
Он просит у сервера конкретную страницу, например «каталог, раздел кресла».
Бэкенд обрабатывает запрос
Программа на сервере понимает, что нужно, и запрашивает у базы данных список кресел с ценами и остатками.
Сервер возвращает ответ
В ответе — HTML: структура страницы со ссылками на CSS (оформление), JavaScript (поведение) и картинки. Эти файлы браузер запрашивает у сервера следующими запросами.
Браузер собирает страницу
Он раскладывает полученные файлы на экране, и вы видите каталог.
Если вы заполняете форму заявки, путь тот же, только в обратную сторону едут ваши данные: браузер отправляет их на сервер, бэкенд проверяет поля и записывает заявку в базу или пересылает менеджеру.
Фронтенд, бэкенд и база данных: кто за что отвечает
- 01ФронтендИнтерфейс в браузере: вёрстка, кнопки, формы, адаптация под телефон
- 02БэкендЛогика на сервере: проверка данных, права доступа, расчёты, связь с другими системами
- 03База данныхХранилище: товары, заказы, пользователи, история изменений
Фронтенд
- Что делает
- Показывает информацию и принимает действия посетителя
- Где работает
- В браузере на устройстве посетителя
- Пример задачи
- Фильтр каталога, корзина, форма заявки
Бэкенд
- Что делает
- Принимает запросы, применяет правила бизнеса, отдаёт ответ
- Где работает
- На сервере
- Пример задачи
- Проверить остаток, посчитать доставку, отправить заявку в CRM
База данных
- Что делает
- Надёжно хранит данные и быстро находит нужные
- Где работает
- На сервере, часто отдельном
- Пример задачи
- Хранить заказы, клиентов, цены
Фронтенд и бэкенд часто пишут разные специалисты и на разных языках. Фронтенд-разработчик отвечает за то, чтобы интерфейс был понятным, быстрым и одинаково хорошо работал на телефоне и компьютере. Бэкенд-разработчик — за то, чтобы данные сохранялись без потерь, правила бизнеса соблюдались, а посторонние не получали доступ к чужой информации. В небольших проектах обе роли может совмещать один человек, но это всё равно две разные зоны ответственности.
Важная деталь: всё, что работает во фронтенде, посетитель теоретически может посмотреть и изменить у себя в браузере. Поэтому проверки, от которых зависят деньги и доступы, — цена в заказе, права пользователя, скидки — всегда должны выполняться на бэкенде.
Статичный и динамический сайт
MDN разделяет сайты на два типа. Статичный сайт отдаёт каждому посетителю одни и те же заранее подготовленные страницы. Динамический собирает страницу в момент запроса — из шаблона и данных из базы, поэтому каждому может показать своё.
Статичный сайт
- Страницы подготовлены заранее и одинаковы для всех
- Нет базы данных — нечему «сломаться» на сервере
- Подходит для визитки, лендинга, портфолио
- Новые страницы добавляет разработчик или генератор при сборке
Динамический сайт
- Страница собирается из шаблона и данных при каждом запросе
- Есть серверная логика и хранилище данных — свои или готовые сервисы
- Нужен для каталога, личного кабинета, бронирования, оплаты
- Содержимое меняется через админку без разработчика
На практике границы размыты. Многие современные сайты собирают страницы заранее, как статичные, а живые части — форму заявки, корзину, расчёт доставки — подключают через бэкенд. Так посетитель получает быструю загрузку, а бизнес — работающие формы и актуальные данные. Выбор подхода зависит не от моды, а от того, что сайт должен делать.
CMS и админка: как вы управляете содержимым
CMS (система управления содержимым) — программа, которая позволяет менять тексты, картинки и товары без знания кода. Админка — её рабочий кабинет: закрытая часть сайта, куда заходят сотрудники, а не посетители. Технически админка — это тоже фронтенд и бэкенд, только для своей команды.
- Тексты страниц, новости и статьи блога
- Товары или услуги: названия, цены, фото, наличие
- Заявки и заказы с формы — с фильтрами и статусами
- Баннеры, акции, контакты и часы работы
- Пользователи админки и их права: кто может только смотреть, кто — редактировать
CMS бывает готовой — её ставят на сайт и настраивают — или написанной под задачу. Готовая подходит, когда нужно править тексты и новости. Своя админка оправдана, когда у бизнеса особые процессы: заявки проходят несколько статусов, товары связаны со складом, у менеджеров разные права. Главное — чтобы админкой было удобно пользоваться вашим сотрудникам, а не только разработчику.
Где живёт код и что должно принадлежать вам
У сайта есть несколько «мест жительства». Исходный код хранится в репозитории — системе контроля версий, где видна вся история изменений. Рабочая копия кода запущена на хостинге или сервере. База данных живёт отдельно и требует регулярных резервных копий. А адрес, по которому всё это открывается, — домен — зарегистрирован у регистратора. Если хотя бы одно из этих мест оформлено только на подрядчика, вы зависите от него.
- Репозиторий с кодом — в аккаунте компании, подрядчик приглашён как участник
- Хостинг или облачный сервер — оплачивается с карты или счёта компании
- Доступ к базе данных и понятное место, где лежат резервные копии
- Учётная запись владельца в админке с правами администратора
- Домен зарегистрирован на компанию, а не на разработчика
- Короткая инструкция: как развернуть сайт заново, если сервер придётся сменить
Хорошо устроенный сайт — это не только красивый фронтенд. Это ещё и понятная кухня, надёжный склад и ключи от всех дверей у владельца.
