Тут имелось в виду: когда мы изменили сигнатуру в спецификации и перегенерировали код, IDE, а затем и компилятор Go выдадут ошибку (несоответствия нашей реализации сервера сгенерированному интерфейсу сервера) на строке с вызовом функции RegisterHandlers.
Компилятор тут при том, что один из этапов компиляции — Type-checking and AST transformations(cmd/compile/internal/gc) — тут происходит магия по авто-типизации, проверка интерфейсов, определение мертвого кода и escape-анализ
Со случаями синхронизации openapi и protobuf не сталкивался, спасибо Вам, что поделились таким интересным опытом! А вот переводить легаси-сервис с http на grpc приходилось, но синхронизация там не требовалась: сервис был полностью доделан. Просто на серваке сначала сделал grpc+http, потом перевел сервисы-клиенты на grpc, затем выпилил http-сервер. Для «чернового» перевода одного в другое сервисов и утилит нашел предостаточно, это радует
Protobuf я упомянул лишь по той причине, что показывал, как у нас устроен репозиторий контрактов, в котором мы храним и генерируем не только openapi, но ещё и proto с cloudevents. Ну и потому, что он изначально с рассчётом на Documentation-Driven разработку создавался
Если нужно какие-то методы, например, дописать - это можно сделать в отдельном файле. А если хочется сгенерированный код переписывать, то это плохая идея (даже IDE об этом предупредит), ибо при повторной генерации изменения пропадут. Лучше изменить шаблон, тогда результат генерации будет воспроизводимым. Этого мы, в том числе, хотим, вводя spec-first подход.
Интересный опыт использования этой библиотеки, круто что ты им поделился!
У нас на проекте была самописная библиотека, в которой, в том числе, есть сервер и клиент. Поэтому искали генератор, которым можно генерировать, используя свой внутренний код. Отсюда такие познания в шаблонах и много примеров с ними)))
Насчёт одного из минусов: для валидаций можно прописывать прямо в OpenAPI спецификации тэг "x-oapi-codegen-extra-tags", в котором прописывать тэг validate, который генерируется и затем обрабатывается пакетом go-playground/validator. Пример: [https://blog.commitsmart.com/go-oapi-codegen-request-validation-285398b37dc8]. Просто если бы я рассказывал об этом в статье, она бы превратилась из лонгрида в лонг-лонгрид, показать на примере ozzo-validation с более понятной логикой мне показалось более наглядным и простым)
Тут имелось в виду: когда мы изменили сигнатуру в спецификации и перегенерировали код, IDE, а затем и компилятор Go выдадут ошибку (несоответствия нашей реализации сервера сгенерированному интерфейсу сервера) на строке с вызовом функции RegisterHandlers.
Компилятор тут при том, что один из этапов компиляции — Type-checking and AST transformations (
cmd/compile/internal/gc) — тут происходит магия по авто-типизации, проверка интерфейсов, определение мертвого кода и escape-анализСо случаями синхронизации openapi и protobuf не сталкивался, спасибо Вам, что поделились таким интересным опытом! А вот переводить легаси-сервис с http на grpc приходилось, но синхронизация там не требовалась: сервис был полностью доделан. Просто на серваке сначала сделал grpc+http, потом перевел сервисы-клиенты на grpc, затем выпилил http-сервер. Для «чернового» перевода одного в другое сервисов и утилит нашел предостаточно, это радует
Protobuf я упомянул лишь по той причине, что показывал, как у нас устроен репозиторий контрактов, в котором мы храним и генерируем не только openapi, но ещё и proto с cloudevents. Ну и потому, что он изначально с рассчётом на Documentation-Driven разработку создавался
Если нужно какие-то методы, например, дописать - это можно сделать в отдельном файле. А если хочется сгенерированный код переписывать, то это плохая идея (даже IDE об этом предупредит), ибо при повторной генерации изменения пропадут. Лучше изменить шаблон, тогда результат генерации будет воспроизводимым. Этого мы, в том числе, хотим, вводя spec-first подход.
Интересный опыт использования этой библиотеки, круто что ты им поделился!
У нас на проекте была самописная библиотека, в которой, в том числе, есть сервер и клиент. Поэтому искали генератор, которым можно генерировать, используя свой внутренний код. Отсюда такие познания в шаблонах и много примеров с ними)))
Насчёт одного из минусов: для валидаций можно прописывать прямо в OpenAPI спецификации тэг "x-oapi-codegen-extra-tags", в котором прописывать тэг validate, который генерируется и затем обрабатывается пакетом go-playground/validator. Пример: [https://blog.commitsmart.com/go-oapi-codegen-request-validation-285398b37dc8]. Просто если бы я рассказывал об этом в статье, она бы превратилась из лонгрида в лонг-лонгрид, показать на примере ozzo-validation с более понятной логикой мне показалось более наглядным и простым)
Я согласен: если OpenAPI спецификации вообще нет, сгенерировать первую, "черновую" версию из кода - отличный ход!