🚧 «Можно ваш API? Нельзя, но можно!»: История про gateway, который никто не хотел давать

Однажды мне понадобилось получать из своего кода данные из сервиса соседней команды. «Легко! — подумал я. — Попрошу их API». Но оказалось, что это начало квеста под названием «дискоммуникация» или «противоречивые требования», выбирайте по настроению.

🔹 Шаг 1: Руководитель vs Разработчик

Я написал в их чат: — Я: Привет! Мне хотелось бы получать от Вас клиента, какой апишкой я могу это сделать из своего сервиса ? — Руководитель команды: Наш сервис нельзя использовать напрямую — только через общий сервис-шлюз для нашего домена! Иначе нарушим архитектуру — Разработчик из их команды: Да берите API нашего внутреннего сервиса. У нас же есть ручка /internal/user-data

Итог: Мне дали API, который «нельзя использовать», но «можно»

🔹 Шаг 2: Gateway, которого нет

Что такое сервис-шлюз ? Это некий сервис, выступающий единой точкой входа в определенный домен. Но, есть одно но, так как этот сервис выступает проксей, он может: - Иметь название API методов, отличные от названий в исходном сервисе - Переопределять метод, сохраняя название - Не изменять ни сам метод, ни его название

Конечно же понять это, когда перед тобой один лишь swagger не удастся, блэк бокс он и в Африке блэк бокс

Мне повезло, вскоре в разговор вошел еще один разработчик и дал мне необходимый метод из gateway, подтвердив, что это то, что я искал

🔹 Почему так вышло?

Разные цели: - Руководитель хотел правильную архитектуру - Разработчик стремился закрыть задачу быстрее.

💡 Вывод:

Коммуникация в больших компаниях — это квест, где много сервисов, много ответственных и, соответственно, много дискоммуникаций. Если вы в чем-то не уверены - не бойтесь призвать к дискуссии более опытных коллег, ведь главное - результат и чем быстрее мы до него доберемся, тем лучше всем. TTM вещь такая 😇

А приходилось ли вам встречать дискоммуникацию в рабочих вопросах?

✈️ Присоединяйся в наше тг сообщество, там больше интересных постов про python, AQA и It