Backend за кнопкой: что происходит между кликом и результатом

Backend — это всё, что происходит за интерфейсом. Когда вы жмёте кнопку на сайте, отправляете форму или оплачиваете заказ — за кулисами работает сервер, база данных, бизнес-логика и интеграции. Это и есть backend.

Звучит как что-то для разработчиков. На самом деле без понимания, что именно стоит за кнопкой, вы не сможете грамотно ставить задачи, выбирать между no-code и кастомным кодом, и оценивать риски готовых сервисов.

Что это

Backend — это серверная часть любого веб-приложения или сайта. Это то, что работает не в браузере пользователя, а где-то «там»: на VPS, в облаке, в serverless-функции или в managed-сервисе.

Если frontend — это витрина магазина, то backend — это склад, кассовый аппарат, бухгалтерия и служба доставки. Покупатель видит только витрину, но за покупкой стоит целая инфраструктура.

Backend — это всё, что работает после того, как запрос ушёл с вашего экрана. Кнопка — это конец frontend, всё остальное — backend.

Граница между frontend и backend проходит по API: frontend отправляет запрос, backend принимает его, обрабатывает по своим правилам, обращается к базе и внешним сервисам и возвращает ответ. Всё, что происходит между приёмом запроса и отправкой ответа, — это и есть backend.

Зачем нужно

• Понимать, как устроен ваш продукт — без этого вы не оцените, где узкое место и почему что-то тормозит.

• Выбирать между no-code и кастомной разработкой — граница проходит именно по возможностям backend.

• Грамотно ставить задачи разработчикам — иначе вы будете объяснять на пальцах и получать не то.

• Оценивать риски готовых сервисов — что они делают с вашими данными, где их backend и кому он доверяет.

• Автоматизировать процессы — любой cron, бот или webhook-обработчик — это маленький backend.

Когда я впервые пытался объяснить клиенту, почему его «корзина на сайте» стоит не 50 тысяч, а 350 — он не понимал, за что платить. После того как мы разложили на схеме сервер, базу, API, бизнес-логику и интеграции с оплатой, вопросы закончились. Backend стал понятным, а не магическим.

Как устроено

Backend состоит из пяти основных слоёв. Они не всегда видны снаружи, но всегда есть — даже если где-то спрятаны за managed-сервисом или low-code платформой.

Сервер

Машина (физическая или виртуальная), на которой работает код приложения. Сервер принимает HTTP-запросы от frontend, обрабатывает их и возвращает ответ. Популярные варианты запуска: VPS (Virtual Private Server), облачные функции (serverless), контейнеры (Docker).

База данных

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

Тип базы данных	Примеры	Когда подходит
Реляционные	PostgreSQL, MySQL	Данные в таблицах со связями: пользователи, заказы, контент.
Документные	MongoDB	Гибкие JSON-документы: логи событий, неструктурированный контент.
Ключ-значение	Redis	Быстрый кеш и очереди: сессии, счётчики, временные данные.

API

Интерфейс, через который frontend общается с backend. Самые распространённые стили:

• REST — запросы по URL с HTTP-методами (GET, POST, PUT, DELETE). Самый простой и понятный.

• GraphQL — один endpoint, клиент запрашивает только нужные поля. Удобно для сложных интерфейсов.

• Webhook — сервис сам отправляет данные при событии. Используется для оплат, уведомлений, интеграций.

Бизнес-логика

Правила, по которым работает приложение: как считать цену с учётом скидки, кому отправить уведомление, когда менять статус заказа. Бизнес-логика — это ядро backend, ради которого всё остальное и существует. Именно здесь сосредоточена основная сложность продукта.

Интеграции

Связи с внешними сервисами: платёжные системы, почтовые рассылки, CRM, мессенджеры, облачные хранилища. Интеграции работают через API или webhook. Каждая интеграция — это потенциальная точка отказа: если внешний сервис лежит, ваш процесс встанет.

Схема: как запрос проходит через backend

flowchart LR
 A["Пользователь"] --> B["Frontend"]
 B --> C["API"]
 C --> D["Backend"]
 D --> E["База данных"]
 D --> F["Внешние сервисы"]
 D --> G["Файловое хранилище"]

Frontend отправляет запрос в API. API передаёт его в backend, тот обращается к базе данных, внешним сервисам и хранилищу, обрабатывает результат и возвращает ответ обратно через API в frontend.

Когда использовать

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

Действие пользователя	Что делает backend
Нажал «Оплатить»	Создал заказ в БД, отправил запрос в платёжную систему, ждёт webhook об оплате.
Заполнил форму обратной связи	Сохранил данные, отправил email менеджеру, создал лид в CRM.
Открыл страницу блога	Запросил контент из БД или CMS, собрал HTML, отдал frontend.
Загрузил файл	Принял файл, сохранил в хранилище, записал метаданные в БД.
Залогинился	Проверил пароль, создал сессию или JWT-токен, вернул frontend.
Действие пользователя	Что делает backend
Нажал «Оплатить»	Создал заказ в БД, отправил запрос в платёжную систему, ждёт webhook об оплате.
Заполнил форму обратной связи	Сохранил данные, отправил email менеджеру, создал лид в CRM.
Открыл страницу блога	Запросил контент из БД или CMS, собрал HTML, отдал frontend.
Загрузил файл	Принял файл, сохранил в хранилище, записал метаданные в БД.
Залогинился	Проверил пароль, создал сессию или JWT-токен, вернул frontend.

Backend и автоматизация

Backend — это не только про сайт. Любая автоматизация, которая работает по расписанию или по событию, — это тоже backend:

• Контент-агент, который обрабатывает инбокс в Notion.

• Скрипт, который каждый день собирает аналитику.

• Бот в Telegram, который принимает заявки.

• Webhook-обработчик, который запускает пайплайн при изменении базы.

Для простых автоматизаций не нужен полноценный сервер. Облачные функции (Vercel, Cloudflare Workers) или low-code платформы (n8n, Make) закрывают большинство сценариев.

Где заканчивается no-code и начинается backend

No-code и low-code инструменты (n8n, Make, Zapier) позволяют строить автоматизации без написания кода. Но у них есть пределы:

• Сложная бизнес-логика с ветвлениями и условиями.

• Высокая нагрузка — тысячи запросов в минуту.

• Нестандартные интеграции — когда нет готового коннектора.

• Безопасность — шифрование, аутентификация, управление правами.

Когда no-code упирается в потолок — появляется кастомный backend.

Начните с no-code. Переходите на кастомный backend только когда упрётесь в ограничения. Преждевременная сложность стоит дороже, чем ограничения no-code.

Пример

Минимальный backend на Node.js + Express. Сервер принимает заявку, сохраняет в файл и возвращает JSON. Для примера не нужна база — файл заменяет её, чтобы было видно всю механику без лишнего.

// server.js
const express = require('express');
const fs = require('fs');
const app = express();
app.use(express.json());

// POST /api/leads — принять заявку
app.post('/api/leads', (req, res) => {
  const lead = {
    name: req.body.name,
    email: req.body.email,
    createdAt: new Date().toISOString(),
  };

  // Бизнес-логика: простая валидация
  if (!lead.email || !lead.email.includes('@')) {
    return res.status(400).json({ error: 'Некорректный email' });
  }

  // Сохраняем в «базу» (JSON-файл вместо настоящей БД)
  const leads = JSON.parse(fs.readFileSync('./leads.json', 'utf-8'));
  leads.push(lead);
  fs.writeFileSync('./leads.json', JSON.stringify(leads, null, 2));

  // Интеграция: отправляем уведомление менеджеру в Telegram
  // (в реальном проекте — через Telegram Bot API)
  console.log('Новая заявка:', lead);

  res.json({ ok: true, id: leads.length });
});

// GET /api/leads — список заявок (для админки)
app.get('/api/leads', (req, res) => {
  const leads = JSON.parse(fs.readFileSync('./leads.json', 'utf-8'));
  res.json(leads);
});

app.listen(3000, () => {
  console.log('Backend запущен: http://localhost:3000');
});

Что здесь видно: сервер принимает запрос, валидирует данные (бизнес-логика), сохраняет в файл (хранение), отправляет уведомление (интеграция) и возвращает ответ. Это и есть backend — всё, что уместилось в 30 строк.

Пример намеренно простой. В реальном проекте файл заменяется на PostgreSQL, уведомления уходят в Telegram через webhook, валидация выносится в отдельный слой, появляется авторизация. Но структура остаётся той же: API → логика → данные → интеграции.

Ограничения

Ограничения

Что учитывать

Backend решает задачу автоматизации и хранения, не магию. Здесь — честные ограничения, с которыми я сталкивался в проектах.

Сложность поддержки

кастомный backend требует разработчика на поддержке, иначе любая мелочь превращается в incident.

Стоимость инфраструктуры — VPS, база данных, мониторинг, бэкапы.

На managed-сервисах счёт идёт за запросы и хранение.

Безопасность — каждая открытая точка API это потенциальная дыра.

Без аудита и обновлений backend быстро проигрывает атакующим.

Vendor lock-in

managed-сервисы удобны, но привязывают вас к своему API и тарифам.

Задержки и таймауты

внешние интеграции могут отвечать по 5-30 секунд, и без асинхронной обработки ваш запрос зависнет.

Согласование версий API

если меняется API, нужно поддерживать обратную совместимость или мигрировать клиентов.

Антипаттерны

Антипаттерны

Чего не делать

Эти ошибки я видел у себя и у клиентов. Каждая — из реального продакшена, не из теории.

Кастомный backend сразу

для простой автоматизации это лишний месяц работы и лишний сервер, который надо поддерживать.

Хранить всё в одной таблице

без нормализации через полгода появятся дубли, противоречия и страдания при правках.

Бизнес-логика в SQL-запросах

сложные запросы превращаются в мешанину, которую никто не может прочитать и безопасно изменить.

Секреты в коде

ключи от платёжки и базы в репозитории = они утекут, вопрос времени.

Игнорировать логирование

без логов вы не поймёте, что сломалось, когда пользователь скажет «ничего не работает».

Без бэкапов

первая же авария с базой без бэкапа заканчивается потерей данных и репутации.

Чеклист

Чеклист

Проверка перед запуском

Перед тем как выкатить backend в продакшен, пройдитесь по этим пунктам.

Граница с frontend ясна

понятно, какие запросы уходят в API и какой формат ответа.

Тип базы выбран

реляционная для связанных данных, документная для гибких, ключ-значение для кеша.

API описан

есть документация endpoints, форматов запросов и ответов.

Интеграции на карте

зафиксировано, какие внешние сервисы используются и как они падают.

Место запуска определено

VPS, serverless, контейнеры — выбрано осознанно под нагрузку и бюджет.

Обработка ошибок продумана

что происходит, когда внешний сервис не отвечает или база недоступна.

Аутентификация настроена

кто имеет доступ к API и какие права у каждой роли.

Логирование и мониторинг

ошибки и аномалии видны без ручного захода на сервер.

Граница с no-code ясна

зафиксировано, что закрывает no-code, а что требует кастомного кода.

Бэкапы настроены

база и критичные файлы сохраняются по расписанию и проверены на восстановление.

Ссылки

Ссылки

• MDN: HTTP-методы и REST

• PostgreSQL: официальная документация

• Express.js: руководство для начинающих

• Cloudflare Workers: serverless-платформа для backend

• n8n: визуальная автоматизация с поддержкой ИИ-агентов

По теме

По теме

• База знаний: API простыми словами: как сервисы разговаривают друг с другом

• База знаний: Webhook простыми словами: как система узнаёт, что что-то произошло

• База знаний: n8n + AI: 7 рабочих сценариев, которые экономят недели