🔌 Внешние интеграции

Короткий ответ Нужно замокать HTTP-слой (через unittest.mock, библиотеки responses/respx/requests-mock или тестовый HTTP-сервер), чтобы тест проверял логику обработки ответа и ошибок, не выполняя реальных сетевых запросов, и отдельно — через contract-тесты или интеграционные тесты против тестового окружения внешнего сервиса — проверять, что реальный контракт не разошёлся с ожиданиями. Как это работает подробнее unit-тесты с моками подменяют HTTP-клиент или сам транспортный слой, задавая заранее подготовленные ответы (успех, разные коды ошибок, таймаут) для проверки, что код правильно обрабатывает каждый случай. Такие тесты быстрые и детерминированные, но не гарантируют, что реальный внешний API ведёт себя так, как в моке. Пример кода Что использовать на практике Рекомендация. стоит разделять уровни тестирования: быстрые unit-тесты с моками для покрытия всех веток обработки ошибок (таймаут, 4xx, 5xx, неожиданный формат ответа), и отдельные (реже запускаемые, например в CI по расписанию или вручную) контрактные

Читать полностьюhttp-client

Короткий ответ GraphQL позволяет клиенту одним запросом запросить произвольный набор полей и связанных сущностей через единый эндпоинт, в отличие от REST с фиксированной формой ответа на фиксированном URL; при этом резолверы для вложенных полей часто вызываются отдельно для каждого элемента списка, что создаёт классический N+1 на уровне резолверов, если не использовать batching (например, DataLoader). Как это работает подробнее в REST сервер решает, какие данные вернуть на конкретный путь; в GraphQL клиент описывает нужную форму ответа в запросе (query), а сервер исполняет граф резолверов, где каждое поле может иметь собственную функцию получения данных, независимо вызываемую для каждого родительского объекта. Пример кода Что использовать на практике Рекомендация. GraphQL решает проблему "недостаточности данных за один запрос" (undersetching) и "избыточности данных" (overfetching), характерные для жёстких REST-ответов, но добавляет сложность на стороне сервера: без батчинга резолвер для поля author у списка и

Читать полностьюdataloader

Короткий ответ N+1 проявляется, когда для одного списка из N объектов сериализатор выполняет по отдельному запросу на связанные данные для каждого элемента; диагностируют по логам SQL-запросов (один запрос на список + N похожих запросов), а устраняют через предварительную загрузку связанных данных одним batched-запросом (eager loading / join / IN-запрос). Как это работает подробнее если эндпоинт возвращает список заказов с полем "имя клиента", а код наивно обращается к order.customer.name для каждого заказа в цикле, при ленивой загрузке ORM это превращается в отдельный SQL-запрос на каждого клиента — при 100 заказах это 1 + 100 запросов вместо одного-двух. Пример кода Что использовать на практике Рекомендация. включить в логи или EXPLAIN количество выполненных запросов на один вызов эндпоинта, сравнить его с ожидаемым (константным, не зависящим от размера списка); в SQLAlchemy использовать joinedload/selectinload, в Django ORM — select_related/prefetch_related, либо вручную собрать все нужные ID и одним запро

Читать полностьюeager-loading

Короткий ответ Нужно заранее решить и явно документировать стратегию для частичного отказа: либо вернуть частичный результат с явным указанием, какие данные недоступны, либо вернуть ошибку целиком — выбор зависит от того, критичны ли данные недоступного сервиса для корректности ответа. Как это работает подробнее при параллельном вызове нескольких внешних сервисов (например, через asyncio.gather с return_exceptions=True) можно получить смесь успешных результатов и исключений; дальше нужно решить для каждого источника данных, является ли он обязательным (и его отказ должен провалить весь запрос) или опциональным (и его отказ допускает деградацию функциональности). Пример кода Что использовать на практике Рекомендация. для некритичных дополнений (например, "рекомендованные товары" на странице заказа) разумно вернуть основной ответ без этого блока и залогировать/замониторить отказ; для критичных данных (например, актуальная цена перед оплатой) лучше вернуть ошибку, чем показать неполную или потенциально устаревшу

Читать полностьюfallback

Короткий ответ Polling — это когда ваш сервис сам периодически опрашивает внешний API, чтобы узнать об изменениях; webhook — это когда внешний сервис сам отправляет HTTP-запрос на ваш URL в момент события, без необходимости постоянно спрашивать. Как это работает подробнее при polling клиент шлёт запросы с интервалом (например, раз в минуту) и сравнивает состояние с предыдущим; при webhook сторонний сервис заранее настраивается на отправку POST-запроса на указанный URL при возникновении события (оплата прошла, статус изменился). Пример кода Что использовать на практике Рекомендация. webhook снижает задержку реакции на событие и нагрузку по сравнению с частым polling, но требует, чтобы ваш сервис был доступен из интернета по HTTPS и мог обработать повторную доставку одного и того же события (внешние сервисы обычно не гарантируют доставку ровно один раз). Polling проще реализовать и тестировать, но создаёт либо задержку, либо лишнюю нагрузку при частом опросе. Подводные камни Риски. не проверять подлинность вход

Читать полностьюevent-driven