Архитектура клиент-сервер
Тема дорожной карты · Backend разработчик
Клиент-серверная архитектура — базовая сетевая модель веба, в которой клиент (браузер, мобильное приложение, CLI-инструмент или другой микросервис) инициирует запросы, а сервер их обрабатывает и возвращает ответы, при этом обе стороны взаимодействуют через чётко определённый протокол. В вебе HTTP/1.1 и HTTP/2 являются доминирующими протоколами запрос/ответ, причём HTTP/2 добавляет мультиплексирование и сжатие заголовков, значительно снижающие задержку; WebSocket и Server-Sent Events (SSE) расширяют модель, поддерживая постоянные двунаправленные или однонаправленные потоковые каналы для приложений реального времени — живых панелей мониторинга или совместного редактирования. Бэкенд-серверы в клиент-серверной архитектуре предоставляют возможности через REST API (ресурсы поверх HTTP с GET, POST, PUT, DELETE), GraphQL-эндпоинты (управляемые схемой запросы через единственный POST /graphql) или gRPC-сервисы (типизированные Protobuf RPC поверх HTTP/2), каждый из которых имеет свои компромиссы в гибкости, типовой безопасности и производительности. TLS (HTTPS) обязателен для любой клиент-серверной коммуникации в продакшене: он шифрует трафик, аутентифицирует сервер через сертификаты X.509 и обеспечивается Nginx или Caddy как TLS-терминирующим обратным прокси перед серверами приложений. Горизонтальное масштабирование серверного уровня в клиент-серверной архитектуре требует stateless серверов приложений (JWT или сессии с Redis вместо состояния сессий в памяти процесса) за балансировщиком нагрузки, а Docker и Kubernetes автоматизируют планирование контейнеров и контролируемые rolling-деплои через CI/CD.
Как это работает
Архитектура клиент-сервер строится на client-server модели: backend экспонирует API (HTTP, gRPC, GraphQL или message-based), который зовут клиенты. Сервер — это процесс на хосте, слушающий порт, принимающий соединения, гоняющий бизнес-логику и читающий/пишущий хранилище. Современные backend'ы — stateless процессы; состояние живёт в БД, кешах, object storage; это позволяет масштабироваться горизонтально, добавляя реплики за балансировщиком. 12-Factor App — канонический baseline для cloud-native backend.
Когда применять
Стройте backend, когда нужно общее состояние между клиентами (multi-user приложения, persistence), границы доверия (нельзя слать секреты в клиент) или тяжёлый compute, который клиент не потянет. Пропустите backend для чистых статичных сайтов (Astro, Hugo, plain HTML) — CDN достаточно. Для realtime multi-user фич (чат, коллаборация) — стек с WebSocket / SSE (Node, Elixir, Go, Phoenix).
Типичные ошибки
Ловушки Архитектура клиент-сервер: "backend" внутри frontend (чувствительная логика в клиентском JS — видна в DevTools); over-engineering с первого дня (микросервисы для приложения на 100 юзеров); игнор 12-Factor (захардкоженный конфиг, состояние на ФС, нет graceful shutdown) — потом платите при контейнеризации; выбор стека по тренду, а не по сильным сторонам команды. Начинайте монолитом с чёткими границами модулей; разделяйте при необходимости.