treone / billing-graduate-work Goto Github PK

Если сервис нотификации (services/notification_api/api) не посылает сообщения около 10 минут, то закрывается активное соединение с кроликом. При следующем запросе на сервис нотификации возникает ошибка.
Как временная мера, создан перехват исключения в services.general.GeneralService._publish_message(), но по хорошему надо перехватить ошибку, реинициировать подключение к кролику и повторить запрос.

Хорошая работа. В целом замечания не существенные связанные с компоновкой бизнес логики. Поэтому можете поправить только то, с чем согласны и на что есть время.

1. Не совсем понял, где в этом сервисе возвраты? Планировалось ли их делать?
2. Конфигурация проекта получилась сложноватой. Например, весь код по оплате (core функциональность) спрятан в utils, куда обычно скидывают всякий хлам, который некуда больше деть =)
3. Вот это ветвление совсем не очевидно. Т.е. по наличию confirmation_url в резльтате обработки платежа мы принимаем дальнейшие решения. Нет более явного способа?
4. Старайтесь не расширять модели без надобности, как вот тут, лучше явно в бизнес логике (в вашем случае это, кажется, BillRepository) дернуть продюсер.
5. Не очень круто, что у вас в бизнес логику протекли кондовые DRF сериализаторы тут, их лучше использовать на уровне DRF-ных же вьюх при валидации. Иначе этот код никак не переиспользовать. Лучше использовать тут pydantic или namedtuple
6. Голые эксепшены - очень плохо тут. Также подобные инеграции лучше выностить в отдельные классы-клиенты, чтобы легко было масштабировать. Опять же в бизнес логику протекли DRF эксепшены тут лучше написать свои AppLogicException и если нужно, то перехватывать их в этом хендлере https://www.django-rest-framework.org/api-guide/exceptions/#custom-exception-handling

3 staged process which :
1 . Consumes messages from Kafka
2 . Templates consumed messages
3 . Send teplated messages to an endpoint .