Comments 6
Не смотрели buf ? Там и сборка контрактов хорошо организована, есть контроль совместимости версий контрактов и в конце концов есть линтинг.
Однозначно! buf очень удобный современный инструмент с поддержкой всего вами перечисленного, я бы отдал предпочтение в его сторону, если бы выбор стоял между protoc и buf.
Там и из коробки генерации кода в пакеты под многие языки, но их Buf Schema Registry (BSR) преподносится как платный софт. Из бесплатного - только Community Plan с только публичными репизотирями и ограничением по их количеству. К тому же, софт заблокирован на территории РФ, к сожалению.
Поэтому и приняли решение делать весь пайплайн вручную на self-hosted серверах, по трудозатратам может оказаться соразмерно с тем же BSR)
Мы просто собираем контракты в пакеты, публикуемые в локальный репозиторий вместе с утилитой на C#, позволяющей на основании proto и конфигурационного файла в json генерировать исходный код на нескольких языках для разных случаев. Вплоть до генерации метаданных для MS SQL и PostgreSQL.
Пакеты собираются под .NET, но возможности MSBuild позволяют использовать их в любых языках.
Необходимость именно пакетов обусловлена тем, что в одной ветке git репозитория контрактов могут содержаться контракты не того сочетания версий, которое требуется конкретному микросервису. А через пакеты легко привязываются контракты разных версий.
Мне, к сожалению, C# и .NET стэк не знаком, но звучит, будто вы решали ту же задачу по упаковке контрактов с поддержкой версионности)
Всегда интересно, как с одной и той же задачей справляются в разных компаниях
Могу поинтересоваться, что это за утилита?
Утилита была написана на C# изначально мной и решала совсем немного задач:
Автоматический мэппинг специфичных типов и генерацию классов. Например, confluent/type/decimal.proto, который, по сути, представляет собой Java BigDecimal и из коробки поддерживается Confluent.
Поддержку кастомных опций в protobuf. Например, позволяющих указать типы данных для T-SQL и PostgreSQL в таком виде: [(confluent.type.options).tsql_type = "nvarchar(10)", (confluent.type.options).pgsql_type = "varchar(10)"] или [(confluent.type.options).sql_type = "decimal(12,3)"].
Поддержку конвертирования типов для Swagger, так как тот же Confluent Decimal в JSON указывать очень неудобно.
Генерацию MS SQL и PostgreSQL типов для автоматического маппинга. Для MS SQL, так как он не поддерживает композитные типы, была сделана генерация типов для табличных переменных с автоматической генерацией ID для связей родитель-потомок, так как в Protobuf используются иерархические структуры данных (flatten)
Сейчас она уже заметно расширена. Добавлена поддержка ClickHouse, Python, прочих метаданных для MS SQL и PostgreSQL. Вплоть до того, что скрипты миграции для СУБД формируются ей же, а сохранение в БД flatten сообщения, полученного по gRPC, занимает буквально три строки кода. На выбор, через BulkCopy/COPY FROM STDIN или через TVP/композитный тип.
То есть, все рутинные операции, которые вытекают из "contract first" могут быть автоматизированы через JSON файл конфигурации этой утилиты, настраиваемого по потребностям в каждом конкретном случае.
Так как разработку утилиты оплачивал клиент, то публиковать её я права не имею.
Способ организации gRPC контрактов и их автоматизация для микросервисов