Designing and implementing a scalable and reliable message-sending service may seem like a challenging and time-consuming task. However, let's explore some key points of implementation in .NET that will help us achieve the desired level of quality and avoid unexpected obstacles. To accomplish this, we will: Explore of some features of the .NET Confluent Kafka driver. Examine real-life use cases of utilizing .NET channels as an InProc Pub/Sub mechanism to enhance application performance. Discuss the usage of Minimal API and understand its limitations. Compare gRPC streaming with HTTP and determine which option is more suitable for our specific scenario.

2. Трошки контексту
● Модуль, що інтегрується у загальну систему управління та дизайну
кампаній
● Займається саме валідацією,шаблонізацією, відправкою, обробкою
відказів
● Може відправляти на різні канали : email / sms / mms / push
● Може бути розгорнутий для окремих клієнтів в клауді або on prem.
● Може гнучко горизонтально масштабуватися

3. Загальна архітектура підсистеми
send request

4. Деплоймент

5. Концептуальний дизайн потоків даних
C count W count
dynamic
capacity N

6. Дизайн воркера

7. Основні дизайн-рішення
● Зберігання оффсетів з Kafka у зовнішньому сховищі
● Зупинка партішенів коли система перевантажена, щоб Kafka не
від’єднала консьюмерів
● Використання баундед-каналів як внутрішньої системи регулювання
доступності, обміну месседжами
● Різні консьюмер групи можуть обробляти одні й тиж самі меседжі :
аналітика/статистика, відправка, повтори та інше
● Максимально гнучкість у конфігуруванні кожного сервісу

8. API

9. API для нових мікросервісів (.NET 7)
● Minimal API vs Controllers
● Minimal API - максимальна гнучкість при написанні коду, краща
декомпозиція - збираємо все що відноситься до ендпойнту в одному
місці.
● Є деякі обмеження, порівнюючі з попередніми підходами

10. Спроба 1: Завантаження файлів в Minimal API

11. Спроба 1: Завантаження файлів в Minimal API
//NotSupportedException: IFromFormMetadata is
only supported for parameters of type
IFormFileCollection and IFormFile.

12. Спроба 2: Завантаження файлів в Minimal API

13. Спроба 2: Завантаження файлів в Minimal API
//415 unsupported media type

14. Спроба 3: Завантаження файлів в Minimal API

15. Спроба 3: Завантаження файлів в Minimal API
//Runtime error: InvalidOperationException: An action
cannot use both form and JSON body parameters.

16. Спроба 4: Завантаження файлів в Minimal API

17. Спроба 4: Завантаження файлів в Minimal API
System.NotSupportedException: IFromFormMetadata is only
supported for parameters of type IFormFileCollection and
IFormFile.

18. Спроба 5: Завантаження файлів в Minimal API

19. Спроба 5: Завантаження файлів в Minimal API
- Код зв’язування моделі здаходиться прямо в ендпойнту
- Swashbuckle не генерує поле в OpenAPI (і як наслідок swagger UI)

20. Спроба 6: Завантаження файлів в Minimal API

21. Більш Generic-рішення ?

22. Спроба 5: Завантаження файлів в Minimal API (1)

23. Спроба 5: Завантаження файлів в Minimal API (2)
Generic OpenAPI Filter
Custom Model Binding

24. gRPC vs HTTP

25. Приклад конфігурування gRPC До яких методів апплаїться
конфігурація
Політики повторів
Стартова затримка: 0..InitialBackOff
Трешхолд затримки
Мультиплікатор
На які помилки автоматично спрацьовує
ретрай
Налаштування транспортного
рівня сокетів
Створення каналу

26. Приклад стрімінгу бінарних даних
Proto3

27. Приклад стрімінгу бінарних даних
Server
Client

28. Pros & Cons
gRPC
✅ Більш гнучкий generic-підхід
✅ Має вбудовану систему повторних
спроб
✅ Може бути Bi-Directional
✅ Має платформо-незалежні контракти
✅ Підтримується Postman’ом (beta).
❗️ Не підтримується APIM
❗️ Більше інфраструктурного коду
HTTP
✅ Відомий всім стандарт, меньше поріг
входу
✅ Мінімум інфраструктурного коду
✅ Має платформо-незалежні контракти
✅ Підтримується навіть чайником
❗️ При роз’єднанні потрібно
організовувати повторні спроби
❗️ Http/2 - підтримує duplex, HttpClient в
його .NET реалізації - ні.

29. Мої висновки
Коли використання gRPC невиправдане
❌ Для підвищення швидкості всередині периметра розподіленої системи
▶️ Можно використовувати protobuf серіалізацію для HTTP(rest) або SignalR
▶️ У випадку хайлоаду можно використовувати асинхронну комунікацію через месседжинг
або стрімінг

30. Мої висновки
Коли використання gRPC виправдане
✅ Коли є необхідність об’єднати багато сервісів на різних технологіях та немає бажання
переписувати моделі
✅ Коли необхідно організувати одно або дво-направлений стрімінг.
✅ Коли необхідно налагодити клієнт-серверну взаємодію в умовах поганого зв’язку

31. Рішення
Імплементувати HTTP та gRPC ендпойнти для наших клієнтів одночасно

32. Дякую за увагу !
Підключайтесь до мого .NET ком’юніті у Telegram