Здравствуйте, Pauel, Вы писали:

P>>>Спека генерируется обычно для внешних клиентов.
P>·>Ну вот тут

Автор: varenikAA
Дата: 07.09.20

сгенерировали. И клиентам пришлось пойти лесом. Добрые вы.
P>То есть, непойми какая проблема у когото, но виноваты мы? Ты адекватен?
Это видимо только ты не понял у кого проблемы. Проблема у Ночного Смотрящего, с которым я тут непосредственно беседую. Именно он перебрал кучу кодогенераторов, плюнул и предложил писать всё ручками.

P>Если это про OpenApi, то с ним большие проблемы. О чем и речь.
Т.е. твой вариант — не использовать никакой openapi и весь код писать руками, как деды завещали и Ночной Смотрящий делает. Так? Или какую альтернативу ты предлагаешь?

P>При чем независимо от того, генерируешь ли ты манифест, или задаёшь руками.
Очень даже зависимо. Вручную сделанный openapi проще поддерживать во вменяемом состоянии.

>> Потому у вас и проблемы с интеграцией в проде, а тех у кого таких проблем нет — считаете богами.
P>Заявление "на проде проблем нет" сводится к неполному профессионализму. Лучше отказаться от предположений "у нас на проде проблем нету", и рассмотреть риски и способы управления ими.
Ты как-то упустил слово _таких_. Этот подход решает вполне определённый класс проблем. Но, ясен пень, не решает все проблемы.

P>Соответственно если у тебя есть тесты прода — пусканул после обновления их сервиса, выявил проблемы, и до того, как юзеры проснулись, уже всё пофиксано.
Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление. А значит юзеры уже имеют проблемы, прямо сейчас, и поздно пить боржоми. Или ты что-то не договариваешь, называя продом SIT или staging, который как прод, но изолирован от пользователей.

P>Пример — сторонний вендор добавил всего лишь метаданные, которые должен был добавлять раньше, но не добавлял. Т.е. просто фиксанул бажок.
И выкатил в прод без тестов интеграции с вами? Так тут проблема в том, что кто-то что-то выкатывает в прод без тестов. Её и надо фиксить. А не пытаться закатить тесты в прод.

P>>>Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.
P>·>Я уже говорил, что такое работает только в маленьких проектах, где все свои, весь код на одном яп примерно одной версии.
P>То есть, вы не смогли промигрировать код на нужную версию яп — всё, большой проект, оло-ло-ло-ло!
Что значит "не смогли"? Тут всё просто. Бюджета нет, проект в состоянии EoL, команду разогнали — никто мигрировать не будет. Ты в большой организации никогда не работал? +100к работников чтобы...

P>·>Опенапи это частный случай. Проблема в другом, в самом подходе code-first. Люди считают свой основной любимый яп — самым лучшим и правильным. Придумать способ развешивания метаданных, чтобы потом сгенерилась спека, а дальше хоть потоп.
P>До тебя не доходит — не надо ничего придумывать — берешь провереное, протестированое решение.
Совершенно верно, и не поспоришь — лучше быть здоровым и богатым, чем больным и бедным. Ну так бери проверенное протестированное решение и в contract-first с openapi, я разрешаю.

P>·>В лучшем случае получается такая схема:
P>·>code1 + метаданные --[generator1]--> spec
P>·>spec --[generator2]--> code2
P>В лучшем случае, я уже сказал, генератор не нужен. Он необходим только для экспорта АПИ.
Продолжай. Что за экспорт АПИ? И что с результатом экспорта потом делать?

P>·>Так вот становится очень печально, когда приходится жонглировать одновременно с code1, метаданные, generator1, generator2 чтобы получился вменяемый code2. В итоге на это дело плюют и, как по ссылке выше, начинают писать code2 вручную и generator1, spec становятся просто бесполезны. Особенно плакать хочется когда внезапно появляется spec --[generator3]--> code3 и т.д.
P>Ты описал типичную картину для OpenAPI, независимо от того, генеришь манифест, или пишешь руками.
Очень даже зависимо. Т.к. цепочка жонглирования становится короче и количество сущностей уменьшается (не нужно писать метаданные, не нужен их парсер и схемогенератор).

P>·>Схема должна быть проще:
P>·>spec --[generator1]--> code1
P>·>spec --[generator2]--> code2
P>Если под spec взять OpenAPI, то получим геморрой, который ты сам же описал выше.
Что значит "взять"? У тебя оно уже вроде есть, но генерится.

P>·>И развешивать метаданные становится просто не нужно.
P>Ну ок — я хочу фремворк XxX-yyy-zzz. Где мне взять генератор для него? Упс!
P>А происходит это просто — стартовали на xxx-yyy-zzz, а в версии 5.0 понадобился OpenAPI
P>Приплызд!
А абсолютно всемогущий безбажный генератор спеки из развешанных метаданных вам бог ниспосылает. Счастливчики, не всем так везёт, вот Ночному Смотрящему и тем погромистам из restapi.moedelo.org не повезло, например.

P>>>большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.
P>·>Это не проблема, это фича.
P>Это проблема — пока найдешь нужную комбинацию, вспотеешь. А если у тебя уже готовый проект, то втиснуть него нечто иное не факт, что выйдет.
А сгенерить нечто полезное почему выйдет из произвольно написанного готового проекта на произвольном фреймворке?

P>И тут приходится писать кодогенератор самому, т.к. другого выхода нет.
Так же придётся писать спекогенератор, что Ночной Смотрящий рассуждал 2 года назад: "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов".

P>>>Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.
P>·>Генератор в принципе относительно примитивная штука, по сути набор текстовых шаблонов. Легко дорабатывается напильником.
P>С чего ты взял, что доработаешь? Фантазии? Использовать или доработать напильником мешает
С того, что это тупо шаблончик типа mustache, результат работы которого надёжно проверяется компилятором. Сделать работающее решение очень просто. На порядок проще, чем придумывать и развешивать метаданные, добавлять дополнительную метаинформацию, обрабатывать всё это дело и пытаться сгенерить хоть что-то полезное из этого.

P>1. например лицензия, GPL какой
P>2. архитектура генератора, где всё огорожено забором
P>3. сложность этого генератора, например, отсутствие тестов. Гы-гы.
Ровно эти же проблемы могут быть и у твоего схемогенератора.

P>То есть, твоя "доработка" по сложности даст примерно то же, что генерация JSON по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов.
Это неправда. Более того, тебе придётся такой генератор писать в любом случае, если ты хочешь хоть как-то использовать спеку. Единственное как можно "решить" эту проблему, это сваять какую-нибудь хрень, вывалить сгенерённую спеку клиентам и сказать, что это их проблема что они потом будут с ней делать. Это именно то, что сделали погромисты тут

Автор: varenikAA
Дата: 07.09.20

.

Здравствуйте, Pauel, Вы писали:

P>>>Спека генерируется обычно для внешних клиентов.
P>·>Ну вот тут

Автор: varenikAA
Дата: 07.09.20

сгенерировали. И клиентам пришлось пойти лесом. Добрые вы.
P>То есть, непойми какая проблема у когото, но виноваты мы? Ты адекватен?
Это видимо только ты не понял у кого проблемы. Проблема у Ночного Смотрящего, с которым я тут непосредственно беседую. Именно он перебрал кучу кодогенераторов, плюнул и предложил писать всё ручками.

P>Если это про OpenApi, то с ним большие проблемы. О чем и речь.
Т.е. твой вариант — не использовать никакой openapi и весь код писать руками, как деды завещали и Ночной Смотрящий делает. Так? Или какую альтернативу ты предлагаешь?

P>При чем независимо от того, генерируешь ли ты манифест, или задаёшь руками.
Очень даже зависимо. Вручную сделанный openapi проще поддерживать во вменяемом состоянии.

>> Потому у вас и проблемы с интеграцией в проде, а тех у кого таких проблем нет — считаете богами.
P>Заявление "на проде проблем нет" сводится к неполному профессионализму. Лучше отказаться от предположений "у нас на проде проблем нету", и рассмотреть риски и способы управления ими.
Ты как-то упустил слово _таких_. Этот подход решает вполне определённый класс проблем. Но, ясен пень, не решает все проблемы.

P>Соответственно если у тебя есть тесты прода — пусканул после обновления их сервиса, выявил проблемы, и до того, как юзеры проснулись, уже всё пофиксано.
Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление. А значит юзеры уже имеют проблемы, прямо сейчас, и поздно пить боржоми. Или ты что-то не договариваешь, называя продом SIT или staging, который как прод, но изолирован от пользователей.

P>Пример — сторонний вендор добавил всего лишь метаданные, которые должен был добавлять раньше, но не добавлял. Т.е. просто фиксанул бажок.
И выкатил в прод без тестов интеграции с вами? Так тут проблема в том, что кто-то что-то выкатывает в прод без тестов. Её и надо фиксить. А не пытаться закатить тесты в прод.

P>>>Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.
P>·>Я уже говорил, что такое работает только в маленьких проектах, где все свои, весь код на одном яп примерно одной версии.
P>То есть, вы не смогли промигрировать код на нужную версию яп — всё, большой проект, оло-ло-ло-ло!
Что значит "не смогли"? Тут всё просто. Бюджета нет, проект в состоянии EoL, команду разогнали — никто мигрировать не будет. Ты в большой организации никогда не работал? +100к работников чтобы...

P>·>Опенапи это частный случай. Проблема в другом, в самом подходе code-first. Люди считают свой основной любимый яп — самым лучшим и правильным. Придумать способ развешивания метаданных, чтобы потом сгенерилась спека, а дальше хоть потоп.
P>До тебя не доходит — не надо ничего придумывать — берешь провереное, протестированое решение.
Совершенно верно, и не поспоришь — лучше быть здоровым и богатым, чем больным и бедным. Ну так бери проверенное протестированное решение и в contract-first с openapi, я разрешаю.

P>·>В лучшем случае получается такая схема:
P>·>code1 + метаданные --[generator1]--> spec
P>·>spec --[generator2]--> code2
P>В лучшем случае, я уже сказал, генератор не нужен. Он необходим только для экспорта АПИ.
Продолжай. Что за экспорт АПИ? И что с результатом экспорта потом делать?

P>·>Так вот становится очень печально, когда приходится жонглировать одновременно с code1, метаданные, generator1, generator2 чтобы получился вменяемый code2. В итоге на это дело плюют и, как по ссылке выше, начинают писать code2 вручную и generator1, spec становятся просто бесполезны. Особенно плакать хочется когда внезапно появляется spec --[generator3]--> code3 и т.д.
P>Ты описал типичную картину для OpenAPI, независимо от того, генеришь манифест, или пишешь руками.
Очень даже зависимо. Т.к. цепочка жонглирования становится короче и количество сущностей уменьшается (не нужно писать метаданные, не нужен их парсер и схемогенератор).

P>·>Схема должна быть проще:
P>·>spec --[generator1]--> code1
P>·>spec --[generator2]--> code2
P>Если под spec взять OpenAPI, то получим геморрой, который ты сам же описал выше.
Что значит "взять"? У тебя оно уже вроде есть, но генерится.

P>·>И развешивать метаданные становится просто не нужно.
P>Ну ок — я хочу фремворк XxX-yyy-zzz. Где мне взять генератор для него? Упс!
P>А происходит это просто — стартовали на xxx-yyy-zzz, а в версии 5.0 понадобился OpenAPI
P>Приплызд!
А абсолютно всемогущий безбажный генератор спеки из развешанных метаданных вам бог ниспосылает. Счастливчики, не всем так везёт, вот Ночному Смотрящему и тем погромистам из restapi.moedelo.org не повезло, например.

P>>>большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.
P>·>Это не проблема, это фича.
P>Это проблема — пока найдешь нужную комбинацию, вспотеешь. А если у тебя уже готовый проект, то втиснуть него нечто иное не факт, что выйдет.
А сгенерить нечто полезное почему выйдет из произвольно написанного готового проекта на произвольном фреймворке?

P>И тут приходится писать кодогенератор самому, т.к. другого выхода нет.
Так же придётся писать спекогенератор, что Ночной Смотрящий рассуждал 2 года назад: "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов".

P>>>Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.
P>·>Генератор в принципе относительно примитивная штука, по сути набор текстовых шаблонов. Легко дорабатывается напильником.
P>С чего ты взял, что доработаешь? Фантазии? Использовать или доработать напильником мешает
С того, что это тупо шаблончик типа mustache, результат работы которого надёжно проверяется компилятором. Сделать работающее решение очень просто, именно поэтому "генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера". На порядок проще, чем придумывать и развешивать метаданные, добавлять дополнительную метаинформацию, обрабатывать всё это дело и пытаться сгенерить хоть что-то полезное из этого, именно поэтому лишь "чисто теоретически я знаю как все таки сделать нормальный генератор".

P>1. например лицензия, GPL какой
P>2. архитектура генератора, где всё огорожено забором
P>3. сложность этого генератора, например, отсутствие тестов. Гы-гы.
Ровно эти же проблемы могут быть и у твоего схемогенератора.

P>То есть, твоя "доработка" по сложности даст примерно то же, что генерация JSON по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов.
Это неправда. Более того, тебе придётся такой генератор писать в любом случае, если ты хочешь хоть как-то использовать спеку. Единственное как можно "решить" эту проблему, это сваять какую-нибудь хрень, вывалить сгенерённую спеку клиентам и сказать, что это их проблема что они потом будут с ней делать. Это именно то, что сделали погромисты тут

Автор: varenikAA
Дата: 07.09.20

.