Какие методы взаимодействия с бэкендом использовали кроме REST API

Что проверяют

Работали ли вы с чем-то кроме fetch к REST-эндпоинтам и понимаете ли, почему выбрали именно этот способ. Следом почти всегда идёт «чем WebSocket отличается от SSE» или «что сложнее с кэшированием в GraphQL».

Как отвечать

Называйте то, с чем реально работали, и к каждому пункту добавляйте причину выбора:

• GraphQL: одна точка входа, клиент сам описывает нужные поля. На фронтенде это Apollo Client, urql или Relay с нормализованным кэшем по id и __typename. Цена: HTTP-кэш почти не помогает, потому что запросы идут POST, выручают persisted queries через GET;
• WebSocket: постоянное двустороннее соединение для чатов, совместного редактирования, биржевых котировок. Браузерный WebSocket сам не переподключается, heartbeat и повторную подписку после обрыва пишете вы. Socket.IO это отдельный протокол поверх, с обычным WebSocket-сервером он не совместим;
• SSE: EventSource, поток событий от сервера к клиенту по обычному HTTP. Переподключается автоматически и присылает Last-Event-ID, чтобы сервер дослал пропущенное. Подходит для уведомлений, прогресса, статусов;
• стриминг ответа: fetch с чтением response.body как ReadableStream, так выводят ответ языковой модели по мере генерации;
• gRPC-Web и Connect: нативный gRPC браузеру недоступен, нужен прокси или совместимый протокол, зато типы генерируются из .proto;
• RPC с общими типами: tRPC или серверные функции фреймворка, когда фронт и бэк живут в одном TypeScript-монорепозитории;
• long polling: запасной вариант, когда постоянные соединения режет прокси.

Где спотыкаются

Говорят, что WebSocket «быстрее HTTP» и его стоит брать всегда. Для редких обновлений он приносит stateful-соединения, особую балансировку и ручное переподключение.

Забывают про лимит соединений SSE по HTTP/1.1: браузер держит не больше шести соединений на домен, и несколько вкладок с EventSource блокируют остальные запросы. По HTTP/2 этой проблемы нет.

Хвалят GraphQL за «один запрос вместо пяти» и не знают про N+1 на сервере, ограничение глубины и сложности запроса и потерю HTTP-кэша.