https://gist.github.com/uthunderbird/cef3b8f1443358a2dcb59311099446b9

Вот пример старого сервиса на основе pika. Попробуйте найти тут бизнес-логику)

Проблемы:
1. Работает синхронно, поскольку использует синхронную библиотеку pika. Из-за этого есть проблемы с сетью и нет возможности запустить несколько воркеров в рамках одного процесса. Чтобы использовать одну общую модель, допустим.
2. Прямо в коде реализовано считывание конфига. Гибко, конечно, но это автоматом подразумевает, что у каждого такого сервиса по сути может быть уникальный конфиг (в реальности даже форматы разные).
3. Обязательно указываются все коллбэки, даже которые не нужны.
4. Вручную прописывается декларация очередей и эксчейнджев. Да и в принципе вся коммуникация с реббитом, можно сказать, прописывается пошагово.

https://github.com/alem-research/mela/blob/main/examples/splitter_service/app.py

Сервисы с использованием Mela будут выглядеть так. Попробуй тут найти тоже бизнес-логику.

Ээ, я бы вот такой код вообще никому бы не показывал. Там дело не в pika (
Ну и как innersource такие вещи еще имеют смысл, наверно (если реально так все плохо с коммуникациями в компании), но для opensource выглядит странненько
(А что, в Python нет ничего аналогично Spring? Чтобы велосипеды не придумывать)

От старой команды достался такой подход: был генератор сервисов, который делал заготовку сервиса (более-менее одинаковый код генерил). Потом разраб уже менял сгенеренное.

Собственно, эта библиотека и есть способ не писать одно и то же сотню раз. И заодно убрать всё что наслоилось в сотнях репозиториев за последние года 4.

Оххх, как все страшно-то....
Я же говорю, для innersource - норм

Ну мне кажется, что проще прикрутить opentracing к одной либе, чем к сотне разных сервисов.

То же самое касается всего остального.

По поводу другого языка - уже есть такая же штука для явы. Для ноды есть неплохая сторонняя библиотека.

но ты же понимаешь что все это повышает специфичность решения.

Про спринг - думал месяца 3 назад точно такую же мысль, но так сходу ничего не вспомнил.

Yep. Поэтому лучше это плагинами делать.

Nop. Лучше комуникацию и инфраструктуру сложную вынести отдельно от процесса системы и пусть висит сайдкаром и общается достаточно тонкой прослойкой которая уже может быть вот этой либкой в 100 строк. Или даже роут простой.

в том и идея Dapr. Тупо проще. И не надо таскать "одинаковый код" между сервисами.

опять же - всякие ретраи в случае если запаблишить сообщение в твоей штуке я не увидел.

в прочем... это точно тема для этого чата?

А они есть)

Ладно. Согласен, что чат чуть-чуть неправильный.

Сайдкары - хороший паттерн, но заменять ими просто библиотеки - дороговато.

помоему норм тема для чата. мне вообще кажется, что  тимлидство это, как раз, на стыке с техскилами. но кое-кто топит за чисто менеджерские функции.

Я!

а я как раз про тебя и вспомнил😁

Но я лишь говорю, что чаще всего просто на людскую составляющую мало обещают внимание, вот и топлю за неё

Нет, кстати, дело именно в pika. Чтобы в этом убедиться, достаточно почитать официальный туториал RabbitMQ по питону, где как раз pika используется. Да, там такое же адище.

Например:
https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/python/emit_log_topic.py

https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/python/receive_logs_topic.py

Паблишер и субскрайбер с одной из глав туториала.

Никому не рассказывайте