Что такое backend: сервер, API, база и всё между ними

В уроке о том, как устроен сайт, backend был «кухней ресторана», а в уроке про HTTP и JSON мы разобрали, из чего состоят запрос и ответ. Здесь посмотрим, что происходит внутри сервера между ними. MDN описывает задачу серверного кода так: проверить присланные данные и сам запрос, сохранить или получить данные из базы и отправить клиенту нужный ответ. На практике один запрос «записаться на стрижку в пятницу в 15:00» проходит примерно такой путь:

Серверный код, в отличие от кода в браузере, имеет полный доступ к операционной системе и может быть написан на любом языке — это MDN отмечает как главное различие клиентской и серверной разработки. Вместе с доступом сервер получает ответственность. Удобно разложить её на пять обязанностей — на примере сервиса онлайн-записи в салон.

Аутентификация и авторизация звучат похоже, но это разные шаги. Аутентификация отвечает на вопрос «кто это?», авторизация — «что ему можно?». Пользователь может быть успешно аутентифицирован и всё равно не иметь права отменить чужую запись. Обоим шагам в направлении посвящены отдельные уроки.

Не всё нужно делать, пока пользователь ждёт ответа. Сохранить запись — нужно: без этого нельзя сказать «вы записаны». А отправить SMS-напоминание, пересчитать отчёт или сжать загруженное фото можно чуть позже. Такую работу выносят в фоновые задачи (background jobs): обработчик запроса кладёт задание в очередь и сразу отвечает, а отдельный процесс-обработчик (worker) забирает задания из очереди и выполняет их.

Методология The Twelve-Factor App описывает это как разные типы процессов: HTTP-запросы обслуживает web-процесс, а долгие фоновые задачи — worker-процесс. Сама очередь — ещё один внешний сервис наравне с базой данных: брокер сообщений вроде RabbitMQ, хранилище Redis или таблица заданий в той же PostgreSQL. Что выбрать, зависит от объёма и требований к надёжности; подробно — в уроке о фоновых задачах.

HTTP по умолчанию не хранит состояние (stateless): каждый запрос для сервера — новый, он не помнит, что этот же браузер секунду назад вошёл в аккаунт. Чтобы «помнить» пользователя, сервер после входа выдаёт cookie с идентификатором сессии, браузер прикладывает его к каждому следующему запросу, а сервер по идентификатору находит данные сессии. Так этот механизм описывает MDN.

Ключевой вопрос — где лежат данные сессии и всё остальное, что нужно помнить между запросами. Соблазнительно положить их в переменную в памяти процесса: это работает на ноутбуке и ломается в продакшене. Twelve-Factor App требует, чтобы процессы приложения были stateless и ничего не делили между собой, а всё, что должно сохраниться, лежало во внешнем хранилище. Причина простая: перезапуск при деплое стирает память процесса, а при нескольких копиях сервера следующий запрос может попасть в другую копию.

Пользователь не видит backend, но и разработчик видит его только через логи. Лог — поток событий: «запрос пришёл», «запись создана», «SMS-сервис ответил ошибкой». Twelve-Factor App советует приложению не управлять файлами логов, а писать события в стандартный вывод (stdout) по одному на строку; собирать, хранить и искать их — задача окружения: хостинга, контейнерной платформы, системы сбора логов.

• Пишите в лог метод, путь, код ответа, длительность и идентификатор запроса — по ним ищут проблему
• Ошибки логируйте со стеком вызовов на сервере, а клиенту отдавайте короткое сообщение без внутренних деталей
• Никогда не пишите в лог пароли, токены, номера карт и полные персональные данные
• Настройки, которые меняются между окружениями — адрес базы, ключи сервисов, — храните в переменных окружения, а не в коде

Последний пункт — тоже из Twelve-Factor App: конфигурация отделена от кода, и проверка простая — код можно было бы в любой момент открыть публично, не раскрыв ни одного ключа. Там же база данных, очередь, почтовый сервис и кэш названы подключаемыми ресурсами (backing services): приложение обращается к ним по адресу из конфигурации и не знает, локальные они или облачные. Заменить одну базу на другую — значит поменять переменную, а не код.

Все обязанности из этого урока одинаковы в любом стеке — меняются язык, инструменты и то, сколько фреймворк делает за вас. MDN замечает, что серверную часть почти никогда не пишут без фреймворка: он берёт на себя маршрутизацию, разбор запросов, сессии, доступ к базе. Фреймворки бывают «всё включено», как Django, и минималистичные, как Express или Flask, где недостающее подключается отдельными библиотеками.

Для учебного проекта выбирайте стек по тому, что вы уже знаете. Пишете фронтенд на JavaScript — начните с Node.js: не нужно учить второй язык одновременно с серверными понятиями. Учите Python — FastAPI даст рабочий API с документацией в несколько десятков строк. Целитесь в крупные компании и банковскую разработку — смотрите на Java и Spring Boot. По нашему опыту, переход между стеками даётся легко, если понятны сами обязанности backend: маршрут, валидация, логика, хранение, права.

Соберите всё вместе на одном сервисе. Салону нужен сайт, где клиент выбирает услугу, мастера и время; администратор видит расписание; клиенту за день до визита приходит напоминание. Прежде чем писать код, нарисуйте backend на бумаге — так вы увидите, какие части нужны и где хранится каждое состояние.

Дальше направление идёт от инструментов к архитектуре. Сначала — Node.js: модули, npm и первый HTTP-сервер без фреймворка. Затем Express: CRUD-API с валидацией и единым форматом ошибок. Параллельные ветки — Java со Spring Boot и Python с FastAPI или Django. После них — аутентификация, авторизация, фоновые задачи, тестирование backend и слои backend-приложения. Для работы с хранением понадобится направление «Базы данных».