Вы открыли веб-приложение, ввели запрос в строку поиска и нажали кнопку. Через секунду на странице появились результаты. Кажется, что сайт просто нашёл нужные данные и показал их. Но за этим действием могут стоять несколько частей системы. Браузер отправляет запрос, сервер проверяет параметры, обращается к базе данных и возвращает ответ. Затем интерфейс показывает результат пользователю. Разберемся на этом примере, чем занимается фронтенд, за что отвечает бэкенд и почему одному приложению часто нужны оба.
Что делает фронтенд
Фронтенд это часть приложения, с которой взаимодействует пользователь. Она показывает страницы, формы, кнопки, списки и сообщения об ошибках. В браузере работает JavaScript, который обрабатывает действия и обновляет интерфейс. Представим каталог курсов. Пользователь вводит слово Python и нажимает «Найти». Фронтенд читает текст из формы, формирует запрос и показывает состояние загрузки. Когда ответ получен, он отображает подходящие курсы.
Для такой работы часто используют React или Next.js. Они помогают строить интерфейс из компонентов, управлять состоянием и связывать данные с отображением. При этом фронтенд не должен решать всё самостоятельно. Если нужно получить закрытые данные пользователя, проверить права доступа или обратиться к платному API с секретным ключом, потребуется доверенная серверная часть.
За что отвечает бэкенд
Бэкенд получает запросы и выполняет серверную работу. Он может обращаться к базе данных, проверять авторизацию, рассчитывать стоимость заказа или вызывать внешний сервис. В примере с каталогом сервер получает слово Python и ищет подходящие записи. При этом он должен проверить параметры поиска, ограничить объём результата и сформировать понятный ответ для клиента.
Для бэкенда можно использовать Django с Django REST Framework. Но серверная логика может находиться и внутри приложения Next.js. Выбор технологии не меняет принципа: данные и действия, требующие доверенного выполнения, должны обрабатываться на подходящей стороне системы. Отдельный сервер не обязательно означает отдельный компьютер. На одном хостинге могут работать и страницы приложения, и API. Разница между фронтендом и бэкендом прежде всего связана с их обязанностями.
Проследим путь одного запроса
Допустим, пользователь открыл приложение и хочет получить сведения о товаре с идентификатором 42. Последовательность действий может выглядеть так:
- Пользователь открывает карточку товара.
- Фронтенд отправляет HTTP-запрос
GET /api/products/42/. - Сервер получает запрос и определяет, какую запись нужно найти.
- Бэкенд обращается к базе данных или другому источнику.
- Сервер возвращает ответ в формате JSON.
- Фронтенд отображает название, описание и цену товара.
Если сервер не нашёл запись, он может вернуть 404 Not Found. Если произошла ошибка доступа к данным, ответ будет другим. Интерфейс должен различать успешный результат и ошибку, а не считать любой ответ готовыми сведениями о товаре.
Это один из способов взаимодействия частей приложения. В Next.js некоторые данные могут загружаться ещё на сервере, до появления страницы в браузере. Но сама задача передачи и обработки данных сохраняется.
Как выглядит запрос в коде
Предположим, приложение предоставляет API по адресу /api/products/42/. В браузерном JavaScript можно запросить данные так:
async function loadProduct(productId: number) {
const response = await fetch(`/api/products/${productId}/`);
if (!response.ok) {
throw new Error(`Ошибка API: ${response.status}`);
}
return response.json();
}
Этот фрагмент не создаёт API. Он только обращается к уже существующему маршруту на том же домене и проверяет HTTP-статус ответа.
Сервер может вернуть, например, такой JSON:
{
"id": 42,
"name": "Курс Python",
"price": 1200
}
После получения данных фронтенд сможет показать название и цену. Но интерфейс не должен считать цену из браузера окончательной для создания заказа. Сервер повторно определяет стоимость по своим данным, когда пользователь переходит к оплате.
Если бэкенд Django размещён на другом домене, понадобится соответствующий адрес API или серверный посредник. Для прямых запросов браузера также нужно учитывать настройки CORS.
Почему нельзя доверять всем данным из браузера
Представим, что пользователь оформляет заказ. Фронтенд отправляет идентификатор товара и количество. Но посетитель может изменить запрос через инструменты разработчика или отправить его самостоятельно. Поэтому сервер не должен принимать произвольную цену, указанную клиентом, как подтверждённую стоимость покупки. Он получает идентификатор товара, проверяет его существование, определяет актуальную цену и рассчитывает итоговую сумму.
Аналогично работает доступ к личным данным. Даже если интерфейс не показывает кнопку открытия чужого заказа, это не защищает API от прямого обращения. Бэкенд должен проверять пользователя и его права. Так проходит граница доверия. Фронтенд помогает человеку пользоваться приложением, но не заменяет серверную проверку операций.
Где хранятся данные
Когда пользователь добавил товар в избранное, приложение может временно запомнить его в состоянии React. После обновления страницы такое значение может исчезнуть.
Если избранное должно сохраняться между устройствами, понадобится постоянное хранилище. Обычно для этого используют базу данных. Сервер связывает записи с пользователем и возвращает разрешённую информацию. При этом база данных и бэкенд не одно и то же. База отвечает за хранение и выборку данных. Бэкенд организует операции приложения и проверяет, кому они разрешены.
В некоторых сервисах, например Supabase, база и готовый API предоставляются вместе. Тогда часть запросов frontend может отправлять напрямую через клиентскую библиотеку, а доступ к строкам ограничивают правилами RLS.
Может ли Next.js быть и фронтендом и бэкендом
Да, Next.js позволяет создавать интерфейс на React, получать данные в серверных компонентах и обрабатывать HTTP-запросы через Route Handlers. Это подходит для приложений, которым достаточно серверной логики внутри одного проекта. Например, серверный обработчик может принять форму, проверить данные и обратиться к внешнему API, не раскрывая ключ браузеру.
Но есть задачи, для которых отдельный Django-бэкенд остаётся необходимым. Например, развитая модель данных, сложные правила доступа, самостоятельное API для нескольких клиентов или существующая серверная система.
В моей статье на Habr о Route Handlers в Next.js разобрано, какие серверные операции можно выполнять внутри App Router.
Как соединяются части реального приложения
В AI-чате фронтенд показывает диалог и принимает сообщения. Бэкенд проверяет пользователя, обращается к языковой модели, обрабатывает ошибки и при необходимости сохраняет историю.
В демонстрационном AI-Chat можно посмотреть интерфейс такого приложения. А в статье «Как связать Django REST Framework и Next.js» отдельно разобрана практическая интеграция двух технологий.
Курс «AI на Django и Next II» показывает, как построить серверную часть на Django, связать её с Next.js, подключить внешние API и настроить авторизацию.
Разница между фронтендом и бэкендом проявляется в пути запроса. Интерфейс принимает действие пользователя и показывает результат. Сервер получает данные, выполняет разрешённые операции и возвращает ответ. Когда эти обязанности разделены, проще понимать, где искать ошибку и какую часть приложения развивать.