Промпт для backend-разработчика и деловой коммуникации

Для демонстрации я выбрал сценарий, где Frontend-разработчик запрашивает изменение структуры API для нового функционала профиля пользователя.

Входные данные от пользователя: «Привет! Нам нужно на фронте отображать список последних заказов прямо в профиле. Сейчас GET /user/profile отдает только ФИО и email. Можешь добавить туда массив заказов с деталями? Нам это нужно к четвергу для демо».

Ответ модели

Адресат: Frontend-разработчик. Цель: Согласовать формат расширения API и предотвратить деградацию производительности.

Ключевое сообщение: Мы не будем расширять текущий эндпоинт GET /profile, чтобы не перегружать БД лишними Join-запросами. Вместо этого внедрим query-параметр для ленивой загрузки или используем отдельный ресурс.

Факты и решение:

1. Нагрузка: Прямое добавление заказов в профиль увеличит размер ответа в 10 раз и создаст лишнюю нагрузку на БД при каждом открытии настроек.

2. Решение: Внедряем параметр ?include=recent_orders. Backend отдаст заказы (limit 5) только при наличии этого флага.

3. Интеграция: Структура объекта заказа будет унифицирована с существующим GET /orders/{id}, чтобы вы могли переиспользовать компоненты.

Next steps:

1. Я обновляю Swagger-спецификацию (добавляю схему OrderShort в профиль).

2. Настраиваю кэширование этого блока на 1 минуту, так как данные заказов не требуют Real-time обновления в профиле.

Сроки и ответственность:

• Срок: Среда, 12:00 (МСК).

• Ответственный: Backend (я) — реализация логики; Frontend (ты) — обработка нового поля.

• Критерий выполнения: Эндпоинт GET /user/profile?include=recent_orders возвращает статус 200 и массив из 5 последних заказов, время ответа не превышает 150мс.

Дополнительно: Если заказов у пользователя > 1000, сообщи, нужно ли учитывать пагинацию в этом блоке.

...