Как спроектировать спецификацию фронтенда для рабочего места менеджера с CRUD заказов?

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

Умеете ли вы превратить расплывчатое «нужна админка для заказов» в документ, по которому фронтенд и бэкенд работают параллельно. От Python-разработчика здесь ждут прежде всего контракт API: следом обычно спрашивают, как описать фильтры, пагинацию и ошибки валидации.

Как отвечать

Спецификация строится от сценариев менеджера, а не от экранов:

• роли и права: кто видит все заказы, кто только свои, кто может отменять. Права проверяются на бэкенде, фронтенд их только отражает;
• экраны: список с фильтрами по статусу, дате, клиенту и сумме, сортировкой и пагинацией; карточка заказа; форма создания и редактирования; история изменений;
• состояния: загрузка, пустой список, ошибка сети, нет прав, конфликт при сохранении. Без них фронтенд додумывает поведение сам;
• статусная модель: какие переходы разрешены, например из new в paid, и где нужно подтверждение. Удаление обычно мягкое, через статус cancelled;
• контракт API: OpenAPI-схема, которую FastAPI строит из моделей Pydantic, а в Django REST Framework генерирует drf-spectacular. Из неё фронтенд получает типизированный клиент;
• пагинация и фильтры: курсорная пагинация для длинных списков, фильтры query-параметрами и явный список полей, по которым разрешена сортировка;
• ошибки: единый формат, например Problem Details по RFC 9457, с ошибками по полям, чтобы подсветить конкретное поле формы;
• одновременное редактирование: ETag и If-Match, при расхождении 412 Precondition Failed, или поле version в теле и ответ 409 Conflict. Фронтенд показывает, что заказ уже изменил другой менеджер.

Отдельно зафиксируйте нефункциональные требования: сколько заказов в списке, допустимое время ответа, аудит действий.

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

Описывают макеты и кнопки, но не API и состояния. Фронтенд получает картинки и потом неделями выясняет формат ошибок.

Считают скрытую кнопку защитой. Без проверки прав на сервере чужой заказ отменяется прямым запросом.

Берут offset-пагинацию на большой таблице с частыми вставками: строки на соседних страницах дублируются и пропадают, а глубокие смещения медленные.