Расскажите про опыт клиент-серверного взаимодействия и настройки
Что проверяют
Понимает ли фронтендер сетевой слой: что реально происходит между кликом и данными на экране. Это разговор про HTTP, коды ответов, заголовки, кэш, авторизацию и про то, как вы договариваетесь с бэкендом о контракте. Заодно смотрят, как вы обрабатываете неуспешные сценарии.
Как отвечать
Опишите свой слой работы с сетью, а не отдельный вызов.
- Контракт: REST или GraphQL, откуда берутся типы (схема OpenAPI и генерация, а не переписанные вручную интерфейсы), как живёт версионирование.
- Клиент: единая обёртка над
fetchили axios, в ней базовый адрес, заголовки, разбор кодов ответа, логирование. - Состояние сервера отдельно от состояния интерфейса: библиотека вроде react-query держит кэш, склеивает одинаковые запросы, повторяет неудачные и обновляет данные в фоне. Это снимает половину ручного кода.
- Отмена и гонки:
AbortControllerпри смене фильтра или уходе со страницы. - Авторизация: где лежит токен, как устроено обновление и что делает клиент, когда 401 пришёл сразу по нескольким запросам.
- Ошибки: разделяйте сетевой сбой, ошибку валидации и ответ пятисотой серии. Пользователю нужны разные сообщения и разное поведение кнопки повтора.
Где спотыкаются
Говорят «настроил CORS на фронтенде». Политику задаёт сервер своими заголовками, браузер её только исполняет, а предварительный запрос OPTIONS многие видят впервые. И это не защита приложения, а ограничение браузера: тот же запрос из консоли уйдёт в любом случае.
Оборачивают fetch в try/catch и считают, что поймали всё. fetch отклоняет промис только на сетевой ошибке, а 404 и 500 приходят как обычный ответ, надо смотреть response.ok. Отсюда интерфейс, который показывает пустой список вместо ошибки.
Не думают про гонку запросов. Пользователь быстро печатает в поиске, ответы возвращаются в произвольном порядке, и на экране оказывается результат предыдущего ввода. Лечится отменой прошлого запроса или проверкой, что ответ относится к текущему значению.