Backend — серверная часть цифрового продукта: она принимает запросы, применяет правила, работает с данными и внешними сервисами, а затем возвращает результат. Пользователь обычно не видит этот процесс, но именно он стоит за отправкой формы, входом в аккаунт и оплатой заказа.
Как устроен путь от кнопки до результата
Веб-приложение обычно включает клиентскую часть (frontend) и серверную часть (backend). Frontend показывает интерфейс и отправляет запросы. Backend проверяет входные данные и права доступа, выполняет бизнес-логику, обращается к хранилищам или внешним системам и формирует ответ.
flowchart LR
A["Пользователь"] --> B["Frontend"]
B --> C["HTTP API"]
C --> D["Backend"]
D --> E["База данных"]
D --> F["Внешние сервисы"]
D --> G["Файловое хранилище"]Аналогия: frontend похож на витрину магазина, а backend объединяет склад, кассу, учёт и обработку доставки. Покупатель видит витрину, хотя выполнение заказа требует нескольких внутренних процессов.
Основные части backend
Серверное приложение и среда выполнения
Серверное приложение принимает запросы, а словом «сервер» часто называют и инфраструктуру, где оно выполняется. Код можно разместить на виртуальном сервере (VPS), в контейнере или в управляемой среде функций.
Например, приложение на Node.js может создать HTTP-сервер, получить объект запроса и сформировать ответ. Во время операций ввода-вывода оно может обращаться к сети, базе данных и файловой системе. Это описано в официальном введении в Node.js.
База данных и другие хранилища
Backend хранит пользователей, заказы, контент и настройки в системах, выбранных под структуру данных и характер нагрузки:
- Реляционные базы (PostgreSQL, MySQL) организуют данные в таблицах и поддерживают связи между ними.
- Документные базы (MongoDB) хранят записи как документы с гибкой структурой.
- Хранилища «ключ — значение» (Redis) подходят для кеша, сессий и быстрых временных данных. Redis также может участвовать в реализации очередей, но очередь сообщений и база этого типа — разные архитектурные роли.
- Объектные хранилища используют для файлов, изображений и резервных копий.
API для запросов между системами
API (Application Programming Interface, программный интерфейс) задаёт правила, по которым frontend или другой сервис обращается к backend.
Распространённые варианты:
- REST использует HTTP-адреса, методы вроде
GET,POST,PUT,PATCHиDELETE, а также коды состояния ответа. - GraphQL позволяет клиенту перечислить нужные поля в запросе. Спецификация определяет язык запросов, систему типов и правила выполнения, но не требует конкретного языка программирования, системы хранения или единственного HTTP-адреса для всех реализаций. Подробности приведены в спецификации GraphQL.
Webhook решает другую задачу: система отправляет HTTP-запрос получателю при наступлении события. Например, платёжный сервис может сообщить магазину об изменении статуса платежа. Подробнее: Webhook простыми словами.
Бизнес-логика
Бизнес-логика описывает правила продукта: как рассчитать цену со скидкой, кто может изменить заказ, когда отправить уведомление и при каких условиях сменить статус. Эти правила должны выполняться на доверенной серверной стороне, а не только в браузере пользователя.
Интеграции
Backend связывается с платёжными системами, CRM, почтовыми сервисами, мессенджерами и облачными хранилищами. Для исходящих действий он вызывает чужой API. Для входящих событий принимает webhook или сообщения из очереди.
Что происходит после действий пользователя
| Действие пользователя | Возможная работа backend | Проверяемый результат |
| Нажал «Оплатить» | Создал заказ, запросил платёжную сессию, принял и проверил уведомление платёжного сервиса | Статус заказа соответствует подтверждённому статусу платежа |
| Отправил форму | Проверил поля, сохранил обращение, поставил уведомление и передачу в CRM в очередь | Обращение получило идентификатор, а повторная отправка не создала нежелательные дубли |
| Открыл страницу блога | Получил контент из CMS или базы данных и вернул данные либо готовый HTML | Клиент получил успешный HTTP-ответ и актуальную версию страницы |
| Загрузил файл | Проверил тип и размер, сохранил объект, записал метаданные | Файл доступен только пользователям с нужными правами |
| Вошёл в аккаунт | Проверил пароль по защищённому хешу, применил ограничения входа, создал сессию или подписанный токен доступа | Защищённый запрос проходит с действующими учётными данными и отклоняется без них |
Эталонный шаблон обработки запроса
Конкретная реализация зависит от стека, но надёжный обработчик обычно проходит одну и ту же последовательность:
- Принимает запрос и присваивает ему идентификатор для трассировки.
- Проверяет формат, размер и обязательные поля входных данных.
- Устанавливает личность пользователя и проверяет его полномочия.
- Выполняет бизнес-правило и фиксирует изменение данных.
- Передаёт долгие или фоновые операции в очередь, если их не нужно завершать до ответа.
- Возвращает понятный HTTP-код и минимально необходимый результат.
- Записывает технические события без паролей, токенов и лишних персональных данных.
Наблюдаемый признак успеха: клиент получает ожидаемый ответ, для повторяемых операций повторная обработка не создаёт нежелательных дублей, а запрос можно найти в журнале по идентификатору.
Backend в автоматизациях
Backend используется и без пользовательского сайта. Процесс может запускаться по расписанию, входящему событию или сообщению из очереди. Примеры:
- агент обрабатывает новые записи в контентной базе;
- сценарий ежедневно собирает аналитику;
- бот принимает заявки и передаёт их в CRM;
- обработчик webhook запускает следующий этап процесса.
Low-code-платформа тоже выполняет серверную работу, хотя управление вынесено в визуальный редактор. В Make, например, сценарий описан как последовательность модулей, передающих и преобразующих данные между приложениями; базовая модель показана в официальном руководстве Make.
Когда подходят функции и low-code
Управляемые функции удобны для HTTP-обработчиков, API-маршрутов и webhook. По документации Vercel Functions, платформа запускает функцию для входящего запроса, автоматически масштабирует число активных экземпляров и может уменьшать его до нуля при отсутствии трафика.
Нагрузка сама по себе не задаёт универсальную границу между low-code, функциями и собственным сервером. Возможности зависят от тарифа, характера вычислений и лимитов конкретной платформы. Например, на странице лимитов Cloudflare Workers по состоянию на 8 сентября 2026 года отдельно указаны число запросов, процессорное время, память, длительность и число подзапросов. Эти параметры нужно оценивать отдельно, а не по одному порогу «запросов в минуту».
Low-code обычно удобен, когда:
- процесс можно выразить доступными триггерами и модулями;
- объём операций укладывается в лимиты и бюджет;
- допустимы возможности платформы по обработке ошибок и наблюдаемости;
- готовые коннекторы поддерживают нужную авторизацию и данные.
Кастомный backend становится оправданным, когда требуется сложная доменная логика, особый протокол, строгий контроль доступа, предсказуемая обработка больших объёмов или архитектура, которую выбранная платформа не поддерживает.
Практичный путь: сначала опишите требования и измеримые ограничения. Затем выберите самый простой вариант, который их выполняет, и заранее определите признаки будущей миграции.
Чеклист быстрой проверки backend
Источники
- Introduction to Node.js
- Vercel Functions — проверено 8 сентября 2026 года
- GraphQL Specification, September 2025
- Create your first scenario — Make Help Center
- Cloudflare Workers limits — проверено 8 сентября 2026 года
Следующий шаг
Если вы выбираете между low-code, управляемыми функциями и кастомным backend, полезно обсудить требования, ограничения и стоимость перехода заранее.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
