Поділюсь діалогом, який відбувся в рамках мого консалтингу. Він ілюструє, як з рівня коду дискусія переходить на архітектурний рівень, а потім на її реалізацію на інфраструктурному. У результаті питання по коду просто відпадають.

➡️➡️➡️
привіт. https://t.me/node_recipes/330. 2 пункт по фільтрам. Я правильно розумію, що ти пропонуєш сплітити такий сервіс на мікросервіси? Я бачу тут 3 варіанти для hybrid apps:
1) Хендлити в фільтрах по транспортам з контексту - if else
2) Ділити транспорти по мікросервісам. Але експірієнс такий собі. Можливо, в монорепозиторії таке виглядає набагато краще.
3) Бутстрапити два різних NestJsApplication в 1 процесі, у кожного додатка свій набір фільтрів. Ти пробував такий варіант?
⬅️⬅️⬅️
я пробував усі варіанти. розкажи мені яку проблему ти хочеш вирішити hybrid apps
➡️➡️➡️
Мікросервісна архітектура. Мікросервіс відповідає за свій власний домен. Скажімо це billing. На ньому лежить відповідальність ловити вебхуки по HTTP транспорту. Але у інших сервісів може з'явитися потреба запитувати інформацію по підписках, платежах користувачів. Це ось такий приклад в вакуумі. Інші мікросервіси спілкуються через NATS IO, у якого є request/reply, pub/sub, streaming. Виходячи з прикладу, один сервіс підтримує 2 транспорти (http, nats).
В ідеалі в сервісі знаходиться доменна логіка, з власними доменними помилками. При різних транспортах, доменна помилка може оброблятися по-різному. Для HttpException ми знаходимо їй статус, для RpcException http статус нам не потрібен, ми там можемо унікальний ідентифікатор їй видати.
І ось власне які підходи я виділяю:
1) Сплітити такий сервіс на 2 різних, у яких тільки свій транспорт - В результаті отримаємо так собі результат за власним досвідом. Якщо врахувати що для k8s probs потрібно http транспорт все одно сетапити для nats мікросервіса
2) Тримати транспорти в 1 сервісі, але тут почнеться ваханалія в інтерцепторах, фільтрах. Вручну додавати UseInterceptors, UseFilter - не дуже добре для експірієнса. Я цілююся все таки на глобальні фільтри, інтерцептори.
⬅️⬅️⬅️
Я б пішов по третьому шляху. Замість того, щоб в API Gateway виставляти всі мікросервіси яким необхідний реалізовувати webhook, я б зробив один такий мікросервіс. Його завдання слухати події (webhook-и) за межами вашої системи і відправляти їх всередину системи. Плюси такого рішення:
- Гарантованість доставки. Не всі зовнішні системи роблять retry як це робить страйп.
- Розділення прийому зовнішньої події і бізнес логіки по її обробці
- Можливість легко прикрутити Event sourcing саме для зовнішніх подій
Мінуси такого рішення
- Очевидно, не підійде, якщо у вас замість web-hooks використовується RPC over http для інтеграції з зовнішніми системами.
➡️➡️➡️
webhook-gateway який слухає всі вебхуки в системі, можна спробувати. Йому не потрібний буде жодний інший транспорт окрім як http. Потрібно буде запаритися над його high availability, RTO, RPO, якщо він буде включати в себе купу фічей системи.
Використовуючи nats jetsteam можна зробити 1 стрім, класти туди всі пейлоди хуків, а консьюмери вже будуть отримувати потрібні відфільтровані сабжекти.
Можна навіть не робити свій сервіс, а взяти API gateway + lambda
⬅️⬅️⬅️
ти правий. нагадую, що lamda/serverless container/k8s це спосіб розгортання вашого коду. спочатку необхідно на архітектурному рівні визначитися, а потім вже на інфраструктурному.