DZ
ну тогда выходит слой который просто конвертирует ошибки
Size: a a a
2020 March 22
BD
Неплохо объяснено
🦉
ну тогда выходит слой который просто конвертирует ошибки
ага. и input тоже
BD
ML
Цели проекта:
Дать на вход спецификацию openapi3, на выходе получить генерированный код, который не нужно править руками. При этом его можно коммитить в репо и смотреть изменения в гите после ручной перегенерации. Можно вынести в отдельный крейт, перегенерировать в ci и деплоить крейт новой версии. Обновлять в проекте, когда будет удобно.
Как использовать:
- Подключается как сервис в main
- В модуле роута импортируются типы request body и response
- actix_swagger::Response используется как аналог actix_web::Response с явными типами ответа, чтобы проверять, что обработчик запроса реализует контракт.
Дать на вход спецификацию openapi3, на выходе получить генерированный код, который не нужно править руками. При этом его можно коммитить в репо и смотреть изменения в гите после ручной перегенерации. Можно вынести в отдельный крейт, перегенерировать в ci и деплоить крейт новой версии. Обновлять в проекте, когда будет удобно.
Как использовать:
- Подключается как сервис в main
- В модуле роута импортируются типы request body и response
- actix_swagger::Response используется как аналог actix_web::Response с явными типами ответа, чтобы проверять, что обработчик запроса реализует контракт.
А. Я видать, не понял суть проекта. Мне, почему-то, казалось, что задача -- генерировать OpenAPI доку из кода, а не наоборот. Жаль, жаль)
🦉
А. Я видать, не понял суть проекта. Мне, почему-то, казалось, что задача -- генерировать OpenAPI доку из кода, а не наоборот. Жаль, жаль)
Обратная схема сильно мешает работать если команда фронта и бекенда сильно разделена.
Мы вынесли спецификацию сваггера в отдельный репо, и любое изменение отправляется через PullRequest, обсуждается всем участвующими сторонами. У нас есть ответственный за спецификацию, который ведет документацию, следит за структурой репо, чтобы всё было консистентно и обрабатывает входящие запросы на новые фичи или изменения.
Поэтому для нас эта тема стала однозначно однонаправленной. Эту спеку все команды используют как единственный источник истины. Все генерируют из нее код. Таким образом получаем консистентное апи без лишних затрат на совпровождение.
А ещё у нас 4 команды: бекенд, фронт, и две мобильные команды
Мы вынесли спецификацию сваггера в отдельный репо, и любое изменение отправляется через PullRequest, обсуждается всем участвующими сторонами. У нас есть ответственный за спецификацию, который ведет документацию, следит за структурой репо, чтобы всё было консистентно и обрабатывает входящие запросы на новые фичи или изменения.
Поэтому для нас эта тема стала однозначно однонаправленной. Эту спеку все команды используют как единственный источник истины. Все генерируют из нее код. Таким образом получаем консистентное апи без лишних затрат на совпровождение.
А ещё у нас 4 команды: бекенд, фронт, и две мобильные команды
DZ
отдельный репник для свогера?
🦉
отдельный репник для свогера?
ага, чисто для спеки
DZ
Обратная схема сильно мешает работать если команда фронта и бекенда сильно разделена.
Мы вынесли спецификацию сваггера в отдельный репо, и любое изменение отправляется через PullRequest, обсуждается всем участвующими сторонами. У нас есть ответственный за спецификацию, который ведет документацию, следит за структурой репо, чтобы всё было консистентно и обрабатывает входящие запросы на новые фичи или изменения.
Поэтому для нас эта тема стала однозначно однонаправленной. Эту спеку все команды используют как единственный источник истины. Все генерируют из нее код. Таким образом получаем консистентное апи без лишних затрат на совпровождение.
А ещё у нас 4 команды: бекенд, фронт, и две мобильные команды
Мы вынесли спецификацию сваггера в отдельный репо, и любое изменение отправляется через PullRequest, обсуждается всем участвующими сторонами. У нас есть ответственный за спецификацию, который ведет документацию, следит за структурой репо, чтобы всё было консистентно и обрабатывает входящие запросы на новые фичи или изменения.
Поэтому для нас эта тема стала однозначно однонаправленной. Эту спеку все команды используют как единственный источник истины. Все генерируют из нее код. Таким образом получаем консистентное апи без лишних затрат на совпровождение.
А ещё у нас 4 команды: бекенд, фронт, и две мобильные команды
у нас так же по командам, но это все в монорепе
DZ
правда вместо мобилы 2 десктоп апы
🦉
тоже думали так делать.
Но монорепа это очень жесть для разного кода.
Имхо, лично мне не хочется видеть 300 коммитов между моим изменением и мастером, если это не касается кода в моей ответственности.
Да и чистую историю получить крайне проблемно. У нас видна история изменений чисто спеки, это упрощает.
Но сам cargo-swagg/actix-swagger никак не помешает юзать его в монорепе
Но монорепа это очень жесть для разного кода.
Имхо, лично мне не хочется видеть 300 коммитов между моим изменением и мастером, если это не касается кода в моей ответственности.
Да и чистую историю получить крайне проблемно. У нас видна история изменений чисто спеки, это упрощает.
Но сам cargo-swagg/actix-swagger никак не помешает юзать его в монорепе
DZ
тоже думали так делать.
Но монорепа это очень жесть для разного кода.
Имхо, лично мне не хочется видеть 300 коммитов между моим изменением и мастером, если это не касается кода в моей ответственности.
Да и чистую историю получить крайне проблемно. У нас видна история изменений чисто спеки, это упрощает.
Но сам cargo-swagg/actix-swagger никак не помешает юзать его в монорепе
Но монорепа это очень жесть для разного кода.
Имхо, лично мне не хочется видеть 300 коммитов между моим изменением и мастером, если это не касается кода в моей ответственности.
Да и чистую историю получить крайне проблемно. У нас видна история изменений чисто спеки, это упрощает.
Но сам cargo-swagg/actix-swagger никак не помешает юзать его в монорепе
ну так проще синхронные изменения делать которые затрагивают много команд
DZ
Ну и версии тоже проще
🦉
ну так проще синхронные изменения делать которые затрагивают много команд
у нас оказалось таких изменений крайне мало.
И все завязаны на спецификацию апи.
При этом деплой делается в другом месте и там же синхронизируется.
Ещё у нас кейс был в том, что спецификация апи и веб уходят в разработке фич дальше, чем апи, а апи уходит дальше чем мобилки.
В итоге, синхронных изменений просто не бывает. Пример: Веб реализовал фичи из версии 1.1, к этому моменту бекенд только завершил 1.0, а мобилки всё ещё делают 1.0. В итоге релизнуть 1.0 ещё нельзя, а веб уже простаивает. Поэтому веб начинает делать 1.2.
И все завязаны на спецификацию апи.
При этом деплой делается в другом месте и там же синхронизируется.
Ещё у нас кейс был в том, что спецификация апи и веб уходят в разработке фич дальше, чем апи, а апи уходит дальше чем мобилки.
В итоге, синхронных изменений просто не бывает. Пример: Веб реализовал фичи из версии 1.1, к этому моменту бекенд только завершил 1.0, а мобилки всё ещё делают 1.0. В итоге релизнуть 1.0 ещё нельзя, а веб уже простаивает. Поэтому веб начинает делать 1.2.
DZ
но потом же ты бек заканчивает версию 1.1 и оказывается на вебе не так что-то и вебу надо возвращаться обратно
🦉
но потом же ты бек заканчивает версию 1.1 и оказывается на вебе не так что-то и вебу надо возвращаться обратно
обычно такого не возникает, так как спецификация проектируется заранее.
🦉
Но по другому сделать нереально. Иначе команда будет простаивать
🦉
Пусть лучше веб внесет правки в 1.1 и выделит больше времени на тестирование и прочее, чем будет простаивать
🦉
Но это у нас такой кейс, в других командах/компаниях могут быть совершенно другие принципы.