Backend-разработка сайтов

Что вообще делает бэкенд на бизнес-сайте

Бэкенд отвечает за всё, что не видно в браузере напрямую: хранение и обработку данных, проверку прав доступа, интеграции с внешними сервисами, отправку писем и уведомлений, расчёты и бизнес-правила. Для типового сайта услуг это может быть скромный слой — обработка формы заявки и отправка в CRM. Для маркетплейса или SaaS-продукта — сложная система с десятками сущностей, ролями и очередями фоновых задач.

Выбор стека: на что реально смотреть

• Доступность разработчиков на рынке под выбранный стек — от этого зависит стоимость поддержки в будущем
• Совместимость с уже существующими системами компании (1С, CRM, внутренние API)
• Реальная нагрузка — не выбирать сложную распределённую архитектуру для сайта с 500 посетителей в день
• Экосистема готовых решений — авторизация, платежи, очереди задач не стоит писать с нуля

Проектирование API: контракт важнее реализации

Хороший API начинается не с кода, а с описания контракта: какие эндпоинты существуют, какие данные принимают и возвращают, какие коды ошибок означают что. Даже без формальной спецификации (OpenAPI/Swagger) стоит зафиксировать это в документе до начала разработки — так фронтенд и бэкенд можно вести параллельно, а не последовательно.

1. Описать ресурсы и действия над ними (создание заявки, получение статуса заказа, обновление профиля)
2. Зафиксировать форматы запроса/ответа и коды ошибок
3. Продумать версионирование API заранее, даже если версия пока одна
4. Определить, что публично, а что требует авторизации

База данных: решения, которые сложно изменить потом

Выбор реляционной (PostgreSQL, MySQL) или документной (MongoDB) базы, схема таблиц и индексы — это решения с высокой стоимостью изменения после запуска. Для большинства бизнес-сайтов с чёткими связями между сущностями (пользователь → заказы → товары) реляционная модель подходит лучше и упрощает будущие отчёты и аналитику. Документные базы оправданы, когда структура данных нестабильна или сильно варьируется между записями.

• Индексы на поля, по которым идёт поиск и фильтрация — до того, как таблица вырастет до миллионов строк
• Внешние ключи и ограничения целостности вместо проверки только в коде приложения
• Миграции как код (а не ручные ALTER TABLE в проде) — для воспроизводимости окружений
• Резервное копирование с проверкой восстановления, а не просто наличием файла бэкапа

Авторизация и права доступа

Для большинства сайтов достаточно классической сессионной или JWT-авторизации с ролями (пользователь, менеджер, администратор). Сложность появляется, когда права нужно проверять не только на уровне роли, но и на уровне конкретного объекта — «менеджер видит только своих клиентов». Такую логику стоит закладывать в архитектуру сразу, а не добавлять патчами позже: переделка модели доступа на живом проекте с данными — одна из самых болезненных задач.

Очереди и фоновые задачи

• Отправка email/SMS — не должна блокировать ответ пользователю, значит, нужна очередь
• Генерация отчётов и экспортов — тяжёлые операции выносятся в фон
• Синхронизация с внешними системами (1С, CRM) — устойчивее работать с ретраями через очередь, чем синхронным запросом
• Cron-задачи для регулярных операций (очистка, пересчёт статусов, напоминания)