Перейти к основному содержимому

Типы веб-приложений и роль бэкенда

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Аналитику Архитектору

Один и тот же бизнес можно вывести в интернет разными способами. От выбора зависят: формат API, кэширование, SEO, сложность деплоя и то, что именно пишет бэкенд-разработчик.

Ось — где собирается HTML​

Словарь​

ТипСутьТипичный API бэкенда
MPA (Multi-Page Application)Каждый URL — новая HTML-страница с сервераФормы POST, сессии, частично REST
SPA (Single Page Application)Одна оболочка HTML, навигация в JSREST/GraphQL, JWT, WebSocket
CSR (Client-Side Rendering)Данные по API, разметка в браузереТолстый JSON, пагинация, BFF иногда
SSR (Server-Side Rendering)HTML собирается на сервере на каждый запросТе же API + слой рендера (Node, .NET Razor, PHP)
SSG (Static Site Generation)HTML генерируется заранее (build)API на этапе сборки + клиентский hydrate
PWAСайт + manifest + service workerКак SPA + push, офлайн-кэш статики

SPA — форма доставки; CSR/SSR/SSG — когда строится DOM. Комбинации нормальны: Next.js = SSR + CSR + SSG в одном проекте.

MPA vs SPA — путь запроса​

Ответ API для SPA (бэкенд отдаёт данные, не разметку):

{
  "id": 42,
  "title": "Кружка",
  "price": 590,
  "in_stock": true
}

SSG / ISR: при сборке CI может вызвать GET /api/articles и сгенерировать HTML в файлы; при ISR страница обновляется по расписанию или по событию — бэкенд дергается на build или по webhook, а не на каждый визит пользователя.

Ответственность бэкенда по типам​

MPA (классика)​

  • Сессии на сервере (cookie + server-side store).
  • CSRF-токены в формах.
  • Меньше версионирования публичного API — логика в контроллерах и шаблонах.
  • SEO «бесплатно» — HTML уже готов.

SPA / CSR​

  • Контрактный API (OpenAPI), версии /v1.
  • CORS, JWT или cookie + SameSite.
  • Пагинация, фильтры, загрузка файлов через API.
  • SEO сложнее — нужен prerender, SSR или отдельный лендинг.

SSR / гибрид​

  • Бэкенд (или BFF) отдаёт HTML и кормит клиентский bundle данными.
  • Важны: время TTFB, кэш фрагментов, не дублировать бизнес-логику в двух слоях без дисциплины.

SSG​

  • На build CI дергает API и пишет статику.
  • Бэкенд для динамики (формы, личный кабинет) остаётся API-first.
  • Обновление контента: rebuild или ISR (инкрементальная регенерация страниц).

BFF (Backend for Frontend)​

Когда мобильному и веб-клиенту нужны разные агрегаты данных, вводят тонкий слой BFF:

  • веб-BFF собирает экран заказа одним запросом;
  • core-сервисы остаются узкими и стабильными.

Минус: ещё один компонент в деплое. Плюс: меньше «чата» на клиенте и проще эволюция UI.

Как выбрать (прагматично)​

КритерийСклонность
SEO критичен, мало интерактиваMPA, SSR, SSG
Богатый UI, редкие индексируемые страницыSPA + CSR
Одинаковый UI web + mobileAPI-first + отдельные клиенты
Максимальная простота хостинга статикиSSG + serverless API

Ошибки проектирования​

  • Два источника правды — бизнес-правила и в Node-рендере, и в Java-сервисе без синхронизации.
  • «Толстый» API для SPA — отдача всей модели БД; нужны DTO и проекции.
  • Сессия в cookie для SPA на другом домене — без продуманного CORS/SameSite ломается авторизация.

Связанные темы​

См. также

Другие статьи этого же раздела в боковом меню (как на странице «О разделе»).

Освоение главы0%