Comments 13
Спасибо. Больше cookiecutter-ов хороших и разных. Но... Комменты на русском. Это значит, что для пет проекта, который мы с парой руссконеговорящих пилим - это не подойдёт.
И да, а зачем в абстрактном методе not implemented?
Привет) У нас в компании уже устаканилось, что в абстрактных методах мы вызываем not implemented. Таким образом мы предотвращаем вызов "заглушек" из дочерних классов, которые просто вызывают метод родительского через super(). Лучше явно вызвать ошибку и показать, что метод действительно не переопределен, чтобы потом не попасться на потенциальный баг. В конце концов на уровне абстрактных классов и интерфейсов мы пытаемся максимально избавится от лишней логики в методах и оставляем ее на реализацию в дочерних классах
А почему в базовом классе репозитория у вас арго/кварги и возвращают методы непонятно что? Если вспомнить LSP, то любая реализация репозитория должна будет тоже поддерживать произвольное количество аргументов. Но в люди случае, сервису непонятно что туда передавать.
Здесь пытаемся максимально абстрагироваться от конкретных реализаций репозитория, поэтому остановились на args и kwargs. Конкретные реализации уже в свою очередь устанавливают свой набор аргументов и тип возвращаемого значения
Вы абстрагировались не от реализаций, вы абстрагировались от здравого смысла. Если метод принимает хз что, хз как его юзать. Если наследники не совместимы с базовыми классом, почему они от него наследуются.
Конкретно наш вариант - это минимальная общая абстракция, которая дает нам гибкость в выборе сигнатуры под конкретный базовый класс, простой компромисс. Если скатываться к строгой типизации, нам придется делать интерфейс под каждую конкретную реализацию
Если есть предложения, как можно этого избежать или улучшить код - не стесняйтесь, пишите
Двигаюсь по похожем пути, но с помощью ии. Это помогает и бек и фронт генерить.
Проверяем, инициализирован ли объект соединения для класса. Если нет, то в переменную класса _connection записываем объект соединения. После этого объект соединения отдается пользователю. Таким образом, даже при множественном вызове метода connect() мы будем получать один и тот же объект соединения.
У вас там походу в коде ошибка - если из двух мест конкурентно дернуть connect проверка на отсутствие коннекта пройдет и пойдут асинхронно создавать два соединение и первое перепишется последующим
Спасибо, поправил с помощью asyncio.Lock
class InstanceConnectionBase(base_proxy.ConnectionProxy):
...
_connection_lock = asyncio.Lock()
...
async def connect(
self, user: base_message_broker.BaseConsumer | base_message_broker.BaseProducer
) -> aio_pika.abc.AbstractRobustConnection:
self._add_connection_user(user)
async with self._connection_lock:
if self._connection is None:
await self._set_connection()
return self._connection
микросервисы - это спорное архитектурное решение, гарантирующее в первую очередь job security архитектору (ни чего другого микросервисы не могут предложить, чего другая архитектура не может).
микросервисы без tracing сервисов? - выстрел в ногу.
бакенд на питоне (не датабрикс / спарк), тоже спорное решение для не пет проектов?
питон без 100% покрытия юнит тестов, это все равно что деплоить не компилящийся код, - выстрел во вторую ногу.
Вы предлагаете микросервисы на питоне без тестов, и трейс логов? ...ну удачи
Хотел написать что-то похожее, но несколько с другим списком пунктов, но потом стер. В любом случае сомнительно, что "подобные проекты могут развивать сообщество backend-разработчиков на Python, привносить свежий взгляд на решение старых проблем". Скорее это решение для небольшой группы разработчиков с близким взглядом на жизнь, которое со стороны вызывает кучу вопросов
микросервисы - это спорное архитектурное решение, гарантирующее в первую очередь job security архитектору (ни чего другого микросервисы не могут предложить, чего другая архитектура не может).
Всё-же что-то могут. Просто таких ситуаций значительно меньше, чем проектов с микросервисами.
Про отсутствие тулинга вокруг люто плюсую. Минимальный уровень инфраструктуры необходимый для них - это высокий уровень для обычных проектов.
Как мы ускорили разработку python-микросервисов с помощью шаблонизатора