Как происходило взаимодействие с фронтендом по чекам

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

Как вы как бэкенд-разработчик договаривались с фронтендом о контракте и понимаете ли специфику чеков: деньги, статусы, повторные запросы. Интервьюер ждёт конкретики вашего проекта, а следом обычно спрашивает, что происходило, когда фронтенд и бэкенд понимали поле по-разному.

Как отвечать

Расскажите про свой проект, выстроив ответ вокруг контракта:

• описание API: OpenAPI-схема, которую FastAPI генерирует сам, а в Django REST Framework даёт drf-spectacular. Фронтенд по ней генерирует типы, а пока эндпоинт не готов, работает на моке;
• деньги: суммы в Decimal на бэкенде и строкой или целыми копейками в JSON, но не float. Отдельно договариваются о валюте, округлении и ставке НДС в каждой позиции;
• статусы: если чек проходит фискализацию через кассовый сервис и ОФД, это асинхронный процесс. Фронтенд получает статус «в обработке» и узнаёт о результате опросом или через WebSocket либо SSE;
• идемпотентность: создание чека принимает ключ идемпотентности, чтобы повтор запроса после таймаута не пробил второй чек;
• ошибки: единый формат с машинным кодом и понятным текстом, например по RFC 9457, коды 400 и 422 для валидации, 409 для конфликта;
• списки: пагинация, фильтры по дате и статусу, сортировка, согласованные с фронтендом заранее;
• доступ: авторизация через JWT или сессионную cookie, CORS только для нужных origin.

Упомяните, как вы синхронизировались: ревью изменений схемы, версии API или правило добавлять поля без удаления старых. Если в проекте всё было проще, например обычный CRUD на Flask, так и скажите и объясните, что улучшили бы сейчас.

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

Передают суммы во float. И в Python, и в JavaScript 0.1 + 0.2 не равно 0.3, а копеечное расхождение в чеке уже ошибка.

Меняют ответ эндпоинта без предупреждения. Переименованное поле ломает экран, который фронтенд уже выкатил.

Делают создание чека синхронным и неидемпотентным. Пользователь нажимает кнопку второй раз, и в налоговую уходят два чека.