Логотип Workflow

Article

Updated at:

Browser To Server Flow

Stage 5. Browser to Server Flow

Когда пользователь нажимает кнопку в браузере, до бизнес-метода на сервере запрос проходит несколько сетевых и инфраструктурных слоев. Если смотреть только на код endpoint-а, легко пропустить настоящую причину ошибки. Поэтому полезно понимать весь путь запроса целиком: от браузера и DNS до gateway, backend-сервиса и ответа обратно.

Browser to server flow

1. Полная цепочка запроса

Обычно путь выглядит так:

  1. Браузер формирует запрос: URL, метод, заголовки, cookie, body.
  2. DNS преобразует домен в IP-адрес.
  3. Запрос проходит через edge-слой: CDN/WAF.
  4. Нагрузку распределяет Load Balancer.
  5. API Gateway применяет правила: auth, rate limit, маршрутизация.
  6. Backend API выполняет бизнес-логику и обращается к БД/кэшу.
  7. Ответ возвращается обратно по цепочке к браузеру.

2. Что делает каждый слой

СлойРоль в цепочкеТипичные проблемы
BrowserСоздаёт HTTP-запрос и применяет политики безопасностиCORS-блокировка, cookie policy, stale cache
DNSРазрешает доменное имя в IPНеверная запись, медленное время резолвинга
CDN/WAFУскоряет доставку и фильтрует трафикСтарая закэшированная версия, блокировка правилом
Load BalancerРаспределяет запросы по инстансамНеправильный health-check, перекос нагрузки
API GatewayПроверяет токен, лимиты, маршрутыПотеря заголовков, лишние ограничения
API ServiceВыполняет бизнес-логикуОшибки в коде, конфликт данных
DB/CacheХранит и отдаёт данныеТаймауты, устаревшие данные

3. Почему 200 OK не всегда означает успех для пользователя

Даже если backend вернул 200, браузер может не дать JavaScript доступ к ответу. Классический случай: API технически отвечает корректно, но CORS-заголовки неполные, и браузер блокирует чтение body. Из-за этого пользователь видит "ничего не работает", хотя сервер в логах выглядит рабочим.

4. Через какие сетевые компоненты идёт запрос

Ниже упрощённая схема для запоминания:

flowchart LR
  A[Browser] --> B[DNS]
  B --> C[CDN/WAF]
  C --> D[Load Balancer]
  D --> E[API Gateway]
  E --> F[API Service]
  F --> G[(DB/Cache)]
  G --> F
  F --> E
  E --> D
  D --> C
  C --> A

Эта цепочка может быть длиннее в реальном проде, но базовая логика почти всегда такая: edge-уровень, маршрутизация, бизнес-сервис, данные, обратный ответ.

5. Мини-чеклист отладки по слоям

  1. В DevTools проверить Network, Headers, Timing и preflight OPTIONS.
  2. Сверить, какие заголовки реально ушли и вернулись (Origin, Authorization, Set-Cookie, Cache-Control).
  3. Проверить X-Request-Id в gateway и backend-логах.
  4. Убедиться, что CDN/прокси не вернули старый ответ из кэша.
  5. Только после этого разбирать бизнес-код endpoint-а.

Практический сценарий

Команда видит, что GET /profile стабильно возвращает 200, но SPA не обновляет экран после логина. Разбор показал, что на API Gateway не прокидывался заголовок Access-Control-Allow-Credentials, и браузер блокировал доступ к ответу при запросе с cookie. После правки CORS-политики, очистки edge-кэша и добавления e2e-проверки сценарий стал стабильным. Этот пример показывает главное: в вебе работает не только endpoint, а вся цепочка от браузера до сервера и обратно.

Авторизуйтесь чтоб пройти тесты

Quiz

Проверьте, что вы усвоили

Practice

Интерактивная практика

Выполните задания и сразу проверьте ответ.