Comments 7
Не слыхал, спасибо.
Действительно похоже на openapi. Стоит пробовать!
Мы используем прото контракт сейчас для генерации ивентов в Кафку имаршвлим в json, но интересно почитать
Ну это как я понимаю в сторонке от кода лежит, может и разъехаться. Да, и в Москве нет Софийской улицы, есть набережная с соответствующим названием
Ну это как я понимаю в сторонке от кода лежит, может и разъехаться
Зависит от инструмента. К примеру, FastStream умеет генерировать AsyncAPI схему из аннотаций типов в коде.
Тем не менее, предполагается, что оно всё-таки где-то в стороне лежит. Не в service_1 , service_2 и service_3?
Иначе выглядит так, что сервис будет знать всех своих потребителей. Уж хорошо это или плохо, каждый сам решает.
Позволяет ли acyncAPI описывать динамический роуминг, где мы, например, по разным топикам и routingKey сообщение в зависимости от типа распихивать? Или routingKey вычисляемый описать? В доку пока не залезал. В примере лишь channel_1 указан. Если позволяет, то уже буду подробно раскуривать.
Тем не менее, предполагается, что оно всё-таки где-то в стороне лежит. Не в service_1 , service_2 и service_3?
Описывать эту схему взаимодействия внутри каждого сервиса кодом или класть рядом .json/.yml - никакой разницы. Мы, например, экспортируем openapi.json в момент релиза, и прикладываем к остальным артефактам.
Иначе выглядит так, что сервис будет знать всех своих потребителей. Уж хорошо это или плохо, каждый сам решает.
OpenAPI описывает, в какой endpoint клиент должен отправить запрос и в каком формате, а также какой ответ он получит. В AsyncAPI тоже самое - в какие топики/очереди клиент должен положить сообщения и в каком формате, а также в каком топике/очереди можно получить результаты (если они есть). Плюс какие требования у этого инстанса Kafka/RabbitMQ/etc по аутентификации. Что дальше будет по цепочке с этими данными, ни AsyncAPI, ни OpenAPI не описывают, - это бизнес-логика тех сервисов, которые из него получают результаты, а не его собственная.
Позволяет ли acyncAPI описывать динамический роуминг, где мы, например, по разным топикам и routingKey сообщение в зависимости от типа распихивать? Или routingKey вычисляемый описать?
Есть подстановки для переменных вроде {userId}, по аналогии с path параметрами в OpenAPI. Либо я не понял вопроса.
UPD: промахнулся, это был ответ на https://habr.com/ru/articles/860604/comments/#comment_27590436
Большое человеческое спасибо! Счастлив, что теперь мне эту статью не писать, буду рекомендовать коллегам для быстрого ознакомления. По asyncapi - третья версия существенно упростила жизнь, прямо глоток воздуха после выверта "в publish описываем куда нам отправлять, а в subscribe - где на нас подписываться". Добавилась +- нативная поддержка таких протоколов, как, например, WebSocket.
Но тулинг - тот случай, когда хотели написать программу, а умеют только в javascript (спасибо, что typescript): с тормозами и плюшками переобобщенного программирования и 100500 паттернов. Впрочем, привычных фротендеру. А не злому бэку, которому пришлось лезть по локоть в modelina, чтобы допилить генережку dto'шек для go, а для плюсов - и вовсе свое писать. Потому что API-First наше всё.
Кстати. На 2.6.0 как то приходилось разделять контексты и документы, и это выглядело довольно нелепо, хотелось DRY. Сейчас я эмпирически оцениваю, где бОльшая доля ответственности, и сдвигаю контекст в этот сервис: теперь же можно описать исчерпывающе входящие-исходящие и ответы. А вы как выбираете, кого из сервисов назначить хозяином API - с чьей перспективы оно описывается?
AsyncAPI — Swagger для брокеров сообщений и не только, или Если хочется иметь структурированную доку по асинхрону