29 октября 2026 г.

У каждого вашего сервиса со временем появляется «хвост» из других сервисов, с которыми он взаимодействует. Шлюз, который изначально вызывал один платежный процессор, обрастает интеграцией с CRM, затем синхронизацией календаря, проверкой соответствия требованиям, и через год никто не может запустить его на своем ноутбуке без VPN до стейджинга или кучи закомментированных вызовов API.

Мы теряем на этом уйму времени. Обычный сценарий: вы клонируете сервис, запускаете его, и он сразу выдает ошибку при вызове какого-нибудь стороннего API, для которого у вас нет учетных данных. Вы начинаете искать по всей кодовой базе каждое место, куда обращается этот сервис. Вы создаете заглушки для всего, что удалось найти, пропускаете одно место и остаток дня тратите на отслеживание трассировки стека, которая появляется только через два сервиса после того, над которым вы работаете.

Самое неприятное — это не создание заглушки для одной зависимости. А поиск всех зависимостей, включая те, которые не находятся в репозитории, который вы просматриваете.

В этом руководстве я настраиваю существующий сервис-шлюз для локальной разработки с помощью Claude Code и плагина Postman. Плагин поставляется с набором инструментов (skills) на GitHub, которые охватывают именно такую работу: один для поиска зависимостей сервиса, другой для создания заглушек для этих зависимостей и третий для проверки того, что заглушки работают корректно.

Узнайте, что вызывает сервис

Я уже подключил к этому шлюзу несколько сторонних интеграций: Nylas для синхронизации календаря, DocuSign, PayPal, Notion и сервис фильтрации текста под названием Pergomalum. Вот запрос, который я дал Claude:

Настрой локальные заглушки Postman для этого сервиса. Я хочу протестировать шлюз, не обращаясь ни к одному из этих реальных внешних сервисов.

Настрой локальные заглушки Postman для этого сервиса. Я хочу протестировать шлюз, не обращаясь ни к одному из этих реальных внешних сервисов.

Прежде чем Claude к чему-либо прикоснулся, он использовал инструмент api-discovery, чтобы проверить Context Graph на наличие всех интеграций, которые вызывает шлюз, а также конечных точек и схем, которые предоставляет каждая из них. Стоит отметить: это не поиск через grep по всей кодовой базе импортов API-клиентов. Context Graph уже знает, какие сервисы существуют и как они связаны, поэтому Claude получил реальный список зависимостей, а не предположение, основанное на том, какие файлы оказались открыты.

Создайте заглушку для каждой зависимости без запуска сервера

Получив список зависимостей, Claude перешел к инструменту api-mocking, обрабатывая по одной интеграции за раз: Pergomalum, затем DocuSign, PayPal, Notion и Nylas.

Инструмент api-mocking может отправить заглушку в облако Postman для получения постоянного URL, но для локальной работы он использует локальные серверы-заглушки Postman — заглушку на основе Git, которая находится прямо рядом с вашими коллекциями в репозитории. Каждая из них получает папку в postman/mocks/ с файлом конфигурации и обработчиком JavaScript для каждого сценария:

Поскольку заглушка представляет собой файлы в репозитории, она перемещается вместе с кодом. Закоммитьте папку postman/mocks/, и следующий человек, который клонирует шлюз, получит те же самые заглушки на тех же портах, не пересобирая ничего.

Настройте шлюз на использование заглушек

Заглушка, работающая на localhost, бесполезна, пока что-то ее не вызовет. Следующим шагом Claude стало обновление конфигурации окружения шлюза, чтобы базовый URL каждой интеграции указывал на ее локальный порт заглушки, а не на реальный API:

Это тот же шаблон переопределения, который описывается в собственной статье Postman о замене внешних зависимостей на локальные заглушки: укажите переменную окружения, которую ваш сервис уже считывает для этой интеграции, на localhost, и тогда ничего в коде шлюза менять не придется.

Проверьте, что заглушки ведут себя как настоящие сервисы

Заглушка, которая запускается без ошибок, — это не то же самое, что заглушка, которая ведет себя правильно. Как только все пять заработали на ожидаемых портах, Claude использовал функцию ad-hoc запросов инструмента api-testing, чтобы проверить каждую из них напрямую. Это включало менее очевидные случаи: переходы состояний PATCH, а также переопределения 404, 422 и 401 для путей с ошибками. Серверы-заглушки Postman поддерживают именно такой тип переопределения кодов состояния и сценариев, что позволяет протестировать, как шлюз обрабатывает ошибку 401 Notion или 422 PayPal, не дожидаясь, пока это произойдет на самом деле.

Что Context Graph улавливает, а репозиторий — нет

Все пять заглушек прошли проверку, но Claude отметил еще две зависимости, которые не были охвачены при первом проходе: calendar-sync-service, который вызывает Nylas напрямую, и demographic-service, который вызывает Pergomalum напрямую. Ни одна из них не была охвачена созданными до этого момента заглушками, потому что эти заглушки соответствовали собственным шаблонам вызовов шлюза, а не шаблонам, которые используют эти два других сервиса.

Важно не то, что обнаружились еще две зависимости. Важно то, что calendar-sync-service вообще отсутствует в этой локальной копии. Он живет в другом репозитории, который я не клонировал. Единственная причина, по которой Claude знал о его существовании и о том, что он вызывает Nylas, — это Context Graph. Локальный поиск или сканер зависимостей, ограниченный текущей файловой системой, пропустили бы его полностью.

Claude подключил оба: demographic-service считывает существующую заглушку Pergomalum, а calendar-sync-service также направляется на существующую заглушку Nylas, при этом файлы сценариев расширены для охвата специфических шаблонов вызовов каждого сервиса. Таким образом, общее количество локальных заглушек, покрывающих всю цепочку, достигло семи, а не пяти.

Превратите настройки в pull-запросы

Заглушки, которые существуют только на одном ноутбуке, мало что стоят. Поскольку настройка зависимостей затронула код более чем в одном репозитории, Claude открыл два pull-запроса: один в репозитории healthcare-demographics, другой в healthcare-infra. Каждый из них содержал переопределения переменных окружения и закоммиченную папку postman/mocks/ для этого сервиса. Любой, кто вытянет эти ветки, получит точно такую же локальную настройку на тех же портах, не выполняя самостоятельно всю эту работу по обнаружению.

Что это вам дает

Ни один из отдельных элементов здесь не является новым. Серверы-заглушки уже давно позволяют разработчикам вести разработку на основе еще не созданного или ненадежного API. Разница в том, что Claude не нужно было говорить, где находится каждая зависимость. Context Graph нашел это, включая ту единственную зависимость, которая находилась в репозитории, который никто не выкачивал. Инструменты плагина позволили перейти от «вот что вызывает что» к работающему локальному окружению, без необходимости вручную переносить эту информацию между этапами.

Стоит сказать прямо: это дает вам рабочее локальное окружение, а не зеленый свет для релиза. Вам все равно нужно тестировать на реальных сервисах, прежде чем что-либо выпускать. Что это действительно дает, так это сэкономленный день. Тот самый, который вы в противном случае потратили бы на поиск каждого места, где сервис обращается вовне, прежде чем вы вообще сможете приступить к изменениям, которые действительно хотели сделать.

Если вы хотите попробовать это самостоятельно, установите плагин Postman для Claude Code и попросите его настроить локальные заглушки для вашего сервиса. Сначала прочитайте о том, как Postman работает в качестве среды локальной разработки, если вы раньше не использовали локальные заглушки.