AO
вместо pydantic на вход и выход могут быть, скажем, protocol buffers
Size: a a a
2020 July 26
AO
тогда будет protocol buffers на входе, потом pydantic in в базу (их может быть несколько, под разные запросы), потом если что-то надо из базы - pydantic out (описание таблицы), и protocol buffers на выход
AO
ну, понятно, что в бинарном виде оно оптимальнее будет
p
тогда будет protocol buffers на входе, потом pydantic in в базу (их может быть несколько, под разные запросы), потом если что-то надо из базы - pydantic out (описание таблицы), и protocol buffers на выход
pb подразумевает типы
AO
да они не связаны с бизнес-логикой, они просто для оптимизации транспорта
AO
они там есть чтобы было эффективнее упаковывать
AO
в общем, общая рекомендация - доверять входным значениям, если они идут от своих сервисов, в то время как за выходными значениями следить жёстко
AO
ну, а если какие-то баги/что-то ещё, если это важно, то можно event sourcing внедрить
AO
и дебажит, разумеется, такое разработчик
p
да они не связаны с бизнес-логикой, они просто для оптимизации транспорта
Ещё раз: был у тебя один тип в транспорте, стал другой. Как все 30 сервисов обновляем?
n🐈
в мастер коммитим
n🐈
ну что за вопрос. держим два транспорта, следующая версия поддерживает оба, следующая только новый
n🐈
ждем три года и все микросервисы обновлены
n🐈
изи
AO
Ещё раз: был у тебя один тип в транспорте, стал другой. Как все 30 сервисов обновляем?
ну, в худшем случае, как с приложениями на MacOS было - запаковывали и для Power'а и для Intel'а
AO
каждому свою версию
AO
это если нет шансов, что это получится быстро обновить
AO
а так вообще, ну, как с СУБД в монолитах, да, делаю новое поле, правильное и переходят на него, старое можно даже не удалять
AO
в protocol buffers это же удобно сделано
p
ждем три года и все микросервисы обновлены
Да я знаю как делается версионирование api :) но это больно и сложно.