Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Большая. Если ты прикрутишь еще и рукопашный OpenAPI, разметка asp.net никуда не денется. НС>·>Разметка может сгенерироваться. Например, если генерировать java по openapi для spring boot НС>Опять пошли по кругу.
Ты сам на этот круг пошел. "разметка asp.net никуда не денется" — ошибка.
НС>·>Ты сам придумал генерацию нескольких моделей по одному описанию. НС>
НС>4. то же описание из 2 используем для генерапции клиентов на Java/C#/JS.
Где здесь несколько моделей? API одно и то же, модель та же, просто на разных яп.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>Вобще то много чего есть. Даже summary берет НС>·>Как я вижу, оно не умеет серверный код генерить. НС>Оно и не должно. Потому что код на C# — первичен, а не наоборот.
Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.
НС>Для любителей писать спеку openapi руками есть другие инструменты.
Какие?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
НС>>Оно и не должно. Потому что код на C# — первичен, а не наоборот. ·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.
Спека генерируется обычно для внешних клиентов. Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.
НС>>Для любителей писать спеку openapi руками есть другие инструменты. ·>Какие?
Предполагаю, тоже фремворки разного рода. Работают вобщем так же — развесил метаданные, либа отдает по ним манифест.
С опенапи есть большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.
Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.
Здравствуйте, Pauel, Вы писали:
НС>>>Оно и не должно. Потому что код на C# — первичен, а не наоборот. P>·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками. P>Спека генерируется обычно для внешних клиентов.
Ну вот тут
сгенерировали. И клиентам пришлось пойти лесом. Добрые вы. Потому у вас и проблемы с интеграцией в проде, а тех у кого таких проблем нет — считаете богами.
P>Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.
Я уже говорил, что такое работает только в маленьких проектах, где все свои, весь код на одном яп примерно одной версии. Там и rest-то не особо нужен. Можно просто описывать api в виде c#-либы. Это не code-first, а code-only. Т.к. отдельные спеки не нужны в принципе.
НС>>>Для любителей писать спеку openapi руками есть другие инструменты. P>·>Какие? P>Предполагаю, тоже фремворки разного рода. Работают вобщем так же — развесил метаданные, либа отдает по ним манифест.
Возможно. Я не видел для шарпа.
P>С опенапи есть
Опенапи это частный случай. Проблема в другом, в самом подходе code-first. Люди считают свой основной любимый яп — самым лучшим и правильным. Придумать способ развешивания метаданных, чтобы потом сгенерилась спека, а дальше хоть потоп.
В лучшем случае получается такая схема:
Так вот становится очень печально, когда приходится жонглировать одновременно с code1, метаданные, generator1, generator2 чтобы получился вменяемый code2. В итоге на это дело плюют и, как по ссылке выше, начинают писать code2 вручную и generator1, spec становятся просто бесполезны. Особенно плакать хочется когда внезапно появляется spec --[generator3]--> code3 и т.д.
Ещё недостаток, что generator1 и generator2 очень разные. Т.к. первый должен уметь парсить язык метаданных и генерить и генерить язык спеки, а второй генератор должен уметь парсить язык спеки и генерить на желаемом языке программирования.
Схема должна быть проще:
spec --[generator1]--> code1
spec --[generator2]--> code2
И развешивать метаданные становится просто не нужно.
И генераторы примерно одинаковые, часто тот же софт, параметры запуска только слегка отличаются, — они оба должны одинаково парсить тот же язык спеки и отличаться только шаблонами генерации на желаемых языках программирования.
P>большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.
Это не проблема, это фича.
P>Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.
Генератор в принципе относительно примитивная штука, по сути набор текстовых шаблонов. Легко дорабатывается напильником.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
сгенерировали. И клиентам пришлось пойти лесом. Добрые вы.
То есть, непойми какая проблема у когото, но виноваты мы? Ты адекватен?
Если это про OpenApi, то с ним большие проблемы. О чем и речь. При чем независимо от того, генерируешь ли ты манифест, или задаёшь руками.
Для OpenAPI нужно
1. хороший фремворк клиента и сервера
2. кодогенератор, который генерирует код под конкретный фремворк
3. возможность расширения/допиливания кодогенератора
Судя по обилию кодогенераторов с разными наборами фич OpenAPI представляет собой большое развлечение.
> Потому у вас и проблемы с интеграцией в проде, а тех у кого таких проблем нет — считаете богами.
Заявление "на проде проблем нет" сводится к неполному профессионализму. Лучше отказаться от предположений "у нас на проде проблем нету", и рассмотреть риски и способы управления ими.
И тут становится ясно, что, например, вендор сервиса, который обновился "а у нас тесты зелёные", может сломать всё, т.к. ты для него всего лишь один из сотен консумеров.
А твои юзера попадут на бабки, т.к. твоя система на проде только хелсчек делает.
Соответственно если у тебя есть тесты прода — пусканул после обновления их сервиса, выявил проблемы, и до того, как юзеры проснулись, уже всё пофиксано.
Пример — сторонний вендор добавил всего лишь метаданные, которые должен был добавлять раньше, но не добавлял. Т.е. просто фиксанул бажок.
Фактически — ничего не сломал. Но благодаря этим изменениям есть огромный шанс, что часть консумеров будут криво работать т.к. их QA тестировали с пакетами записаными с прода. Гы-гы.
P>>Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию. ·>Я уже говорил, что такое работает только в маленьких проектах, где все свои, весь код на одном яп примерно одной версии.
То есть, вы не смогли промигрировать код на нужную версию яп — всё, большой проект, оло-ло-ло-ло!
P>>С опенапи есть ·>Опенапи это частный случай. Проблема в другом, в самом подходе code-first. Люди считают свой основной любимый яп — самым лучшим и правильным. Придумать способ развешивания метаданных, чтобы потом сгенерилась спека, а дальше хоть потоп.
До тебя не доходит — не надо ничего придумывать — берешь провереное, протестированое решение.
·>В лучшем случае получается такая схема: ·>code1 + метаданные --[generator1]--> spec ·>spec --[generator2]--> code2
В лучшем случае, я уже сказал, генератор не нужен. Он необходим только для экспорта АПИ.
·>Так вот становится очень печально, когда приходится жонглировать одновременно с code1, метаданные, generator1, generator2 чтобы получился вменяемый code2. В итоге на это дело плюют и, как по ссылке выше, начинают писать code2 вручную и generator1, spec становятся просто бесполезны. Особенно плакать хочется когда внезапно появляется spec --[generator3]--> code3 и т.д.
Ты описал типичную картину для OpenAPI, независимо от того, генеришь манифест, или пишешь руками.
·>Схема должна быть проще: ·>spec --[generator1]--> code1 ·>spec --[generator2]--> code2
Если под spec взять OpenAPI, то получим геморрой, который ты сам же описал выше.
·>И развешивать метаданные становится просто не нужно.
Ну ок — я хочу фремворк XxX-yyy-zzz. Где мне взять генератор для него? Упс!
А происходит это просто — стартовали на xxx-yyy-zzz, а в версии 5.0 понадобился OpenAPI
Приплызд!
P>>большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi. ·>Это не проблема, это фича.
Это проблема — пока найдешь нужную комбинацию, вспотеешь. А если у тебя уже готовый проект, то втиснуть него нечто иное не факт, что выйдет.
И тут приходится писать кодогенератор самому, т.к. другого выхода нет.
P>>Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера. ·>Генератор в принципе относительно примитивная штука, по сути набор текстовых шаблонов. Легко дорабатывается напильником.
С чего ты взял, что доработаешь? Фантазии? Использовать или доработать напильником мешает
1. например лицензия, GPL какой
2. архитектура генератора, где всё огорожено забором
3. сложность этого генератора, например, отсутствие тестов. Гы-гы.
То есть, твоя "доработка" по сложности даст примерно то же, что генерация JSON по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов.
сгенерировали. И клиентам пришлось пойти лесом. Добрые вы. 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 по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов.
Это неправда. Более того, тебе придётся такой генератор писать в любом случае, если ты хочешь хоть как-то использовать спеку. Единственное как можно "решить" эту проблему, это сваять какую-нибудь хрень, вывалить сгенерённую спеку клиентам и сказать, что это их проблема что они потом будут с ней делать. Это именно то, что сделали погромисты тут
Здравствуйте, Serginio1, Вы писали:
S>·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками. S>Зачем писать для клиента руками?
Ты за дискуссией не следишь? Это предлагает
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками. S>>Зачем писать для клиента руками? ·>Ты за дискуссией не следишь? Это предлагает
Ночной Смотрящий, у него и спрашивай, ему советы и давай.
Это было еще в 20 году. Сейчас уже 23 скоро. Этих генераторов сейчас как собак нерезанных.
НС кстати тогда и писал
В свое время перебрали пачку генераторов и пришли к выводу что писать клиентов нужно руками.
Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.
и солнце б утром не вставало, когда бы не было меня
Ночной Смотрящий, у него и спрашивай, ему советы и давай. S>Это было еще в 20 году. Сейчас уже 23 скоро. Этих генераторов сейчас как собак нерезанных.
Ёлок много и тебя много! А толку — маловато будет!
S>НС кстати тогда и писал S>
S>В свое время перебрали пачку генераторов и пришли к выводу что писать клиентов нужно руками.
S>Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.
Угу. И космические корабли бороздят просторы вселенной.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>>Зачем писать для клиента руками? S>>·>Ты за дискуссией не следишь? Это предлагает
Ночной Смотрящий, у него и спрашивай, ему советы и давай. S>>Это было еще в 20 году. Сейчас уже 23 скоро. Этих генераторов сейчас как собак нерезанных. ·>Ёлок много и тебя много! А толку — маловато будет!
То есть ты эксперт в нетовских генераторах Rest клиентов?
Или тебе Рабинович напел?
Ошибки находятся и исправляются. Без ошибок никто не пишет
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
·>Это видимо только ты не понял у кого проблемы. Проблема у Ночного Смотрящего, с которым я тут непосредственно беседую. Именно он перебрал кучу кодогенераторов, плюнул и предложил писать всё ручками.
Сам подумай, что это значит — кодогенераторы в общей массе отстой. И именно ты топишь за использование тех, которые отстой.
P>>Если это про OpenApi, то с ним большие проблемы. О чем и речь. ·>Т.е. твой вариант — не использовать никакой openapi и весь код писать руками, как деды завещали и Ночной Смотрящий делает. Так? Или какую альтернативу ты предлагаешь?
Очевидно, что не так. Я пишу — использовать проверенную оттестированую либу, но тебе мерещится "писать весь код руками"
Похоже, ты снова начал валять дурака и откровенно передергивать.
P>>При чем независимо от того, генерируешь ли ты манифест, или задаёшь руками. ·>Очень даже зависимо. Вручную сделанный openapi проще поддерживать во вменяемом состоянии.
Как мы выяснили, у OpenAPI проблема не с манифестом, а с кодогенерацией.
Поскольку кодогенераторы для OpenAPI кривые, шо сабля, то тебе надо точно знать фичи кодогенератора, и избегать лишнего в манифесте
В противном случае лишняя строчка в манифесте или сломает клиент, или сломает сервер, или просто проигнорится
И то, и другое, и третье есть проблема
Поэтому в своём уме никто манифест OpenAPI руками не набивает.
P>>Заявление "на проде проблем нет" сводится к неполному профессионализму. Лучше отказаться от предположений "у нас на проде проблем нету", и рассмотреть риски и способы управления ими. ·>Ты как-то упустил слово _таких_. Этот подход решает вполне определённый класс проблем. Но, ясен пень, не решает все проблемы.
А раз не решает все, то часть останутся на проде. Гы-гы. Откуда и следует, что нужно тестировать и прод. Например — при обновлении 3rd party зависимостей.
P>>Соответственно если у тебя есть тесты прода — пусканул после обновления их сервиса, выявил проблемы, и до того, как юзеры проснулись, уже всё пофиксано. ·>Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление.
Алё — они поменяли свой сервис глядя в свои тесты. И подломали некоторые запросы твоего сервиса.
·>И выкатил в прод без тестов интеграции с вами? Так тут проблема в том, что кто-то что-то выкатывает в прод без тестов.
Это норма, а не проблема. Крупные вендоры апи имеют десятки и сотни тысяч консумеров. Ты для них один из сотен тысяч.
Например, ты заюзал sendgrid или mailgun. Они трохи обновились. Ты же фанат емейлов и всё такое. И вот после их обновления часть ваших юзеров перестала получать уведомления. Гы-гы.
Пускаешь тесты прода и видишь, что емейлы таки глючат. Опаньки!
P>>То есть, вы не смогли промигрировать код на нужную версию яп — всё, большой проект, оло-ло-ло-ло! ·>Что значит "не смогли"? Тут всё просто. Бюджета нет, проект в состоянии EoL, команду разогнали — никто мигрировать не будет. Ты в большой организации никогда не работал? +100к работников чтобы...
Тогда это не признак большого проекта, а скорее признак тухлого проекта, который еле держится на плаву.
·>Совершенно верно, и не поспоришь — лучше быть здоровым и богатым, чем больным и бедным. Ну так бери проверенное протестированное решение и в contract-first с openapi, я разрешаю.
Мы уже выяснили — бредогенераторов для openapi 100500 единиц, и почти все из них или не подходят, или их нельзя использовать
Типичный кейс — понадобилась некоторая фича, а кодогенератор не поддерживает, приплызд
P>>В лучшем случае, я уже сказал, генератор не нужен. Он необходим только для экспорта АПИ. ·>Продолжай. Что за экспорт АПИ? И что с результатом экспорта потом делать?
Экспорт АПИ — это ты предоставляешь АПИ своего сервиса внешним консумерам.
P>>Ты описал типичную картину для OpenAPI, независимо от того, генеришь манифест, или пишешь руками. ·>Очень даже зависимо. Т.к. цепочка жонглирования становится короче и количество сущностей уменьшается (не нужно писать метаданные, не нужен их парсер и схемогенератор).
Теоретик?
1 Тебе надо держать в уме возможности кодогенератора. Заюзал ты ResponseHeaders, а у тебя такое не поддерживается. Гы-гы.
2 Метаданные парсить не нужно, это типизированый интерфейс, по которому генерить что угодно легко и просто.
3 Вместо схемогенератора у тебя кодогенератор, при чем — два штуки, каждый со своими особенностями, клиент и сервер.
P>>·>Схема должна быть проще: P>>·>spec --[generator1]--> code1 P>>·>spec --[generator2]--> code2 P>>Если под spec взять OpenAPI, то получим геморрой, который ты сам же описал выше. ·>Что значит "взять"? У тебя оно уже вроде есть, но генерится.
"Взять" — подставляем вместо spec в твоей форумуле успеха OpenAPI, и проверяем твою гипотезу
И оказывается, что именно здесь получается бред, который ты сам же и описал.
P>>Приплызд! ·>А абсолютно всемогущий безбажный генератор спеки из развешанных метаданных вам бог ниспосылает. Счастливчики, не всем так везёт, вот Ночному Смотрящему и тем погромистам из restapi.moedelo.org не повезло, например.
С генератором спеки гораздо проще. Кодогенератор это намного более сложная задача.
Я например писал и то, и другое. Кодогенератор это хтонический ужос по сравнению с генерацией джсон по метаданным.
P>>Это проблема — пока найдешь нужную комбинацию, вспотеешь. А если у тебя уже готовый проект, то втиснуть него нечто иное не факт, что выйдет. ·>А сгенерить нечто полезное почему выйдет из произвольно написанного готового проекта на произвольном фреймворке?
Генерится не из произвольно написаного кода, а из метаданных которые предоставляются либой. Они по своей природе навешиваются на что угодно без проблем.
P>>И тут приходится писать кодогенератор самому, т.к. другого выхода нет. ·>Так же придётся писать спекогенератор, что Ночной Смотрящий рассуждал 2 года назад: "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов".
Он пишет про другое — ты внимательно прочитай.
P>>С чего ты взял, что доработаешь? Фантазии? Использовать или доработать напильником мешает ·>С того, что это тупо шаблончик типа mustache, результат работы которого надёжно проверяется компилятором.
компилер говорит тебе, что выхлоп компилируется. А что выхлоп нерабочий или содержит не то, или не содержит того, никакой компилер тебе не подскажет.
> Сделать работающее решение очень просто, именно поэтому "генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера".
Наоборот — генераторы приходится писать, потому что они в основной массе ни на что не годятся. Берешь генератор кода, и вдруг оказывается, что в генеренном коде нужен хук для инструментирования.
А его нет. Гы-гы. Надо писать новый генератор, потому что допилить напильником не выходит из за GPL лицензии.
> На порядок проще, чем придумывать и развешивать метаданные, добавлять дополнительную метаинформацию, обрабатывать всё это дело и пытаться сгенерить хоть что-то полезное из этого, именно поэтому лишь "чисто теоретически я знаю как все таки сделать нормальный генератор".
Еще раз — не надо придумывать метаданные. Алё, ты вообще читаешь? Берем проверенную либу, закладываемся на её возможности.
P>>1. например лицензия, GPL какой P>>2. архитектура генератора, где всё огорожено забором P>>3. сложность этого генератора, например, отсутствие тестов. Гы-гы. ·>Ровно эти же проблемы могут быть и у твоего схемогенератора.
Нисколько. Схемогенератор это простая вещь по сравнению с кодогенератором.
P>>То есть, твоя "доработка" по сложности даст примерно то же, что генерация JSON по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов. ·>Это неправда. Более того, тебе придётся такой генератор писать в любом случае, если ты хочешь хоть как-то использовать спеку.
Снова теоретизирования Нам нужно проверить, что схема валидная. Мы берем готовый тул, который умеет слать запросы по такой спеке, и пишем под него тесты. Здесь у нас ровно 0 генеренного кода.
> Единственное как можно "решить" эту проблему, это сваять какую-нибудь хрень, вывалить сгенерённую спеку клиентам и сказать, что это их проблема что они потом будут с ней делать. Это именно то, что сделали погромисты тут
Ты высек сам себя — по твоей ссылке пример работы бредо кодогенератора. Этот бредогенератор такое нагенерил, что ни руками вычистить, ни внятно использовать нельзя.
Здравствуйте, Serginio1, Вы писали:
S>·>Ёлок много и тебя много! А толку — маловато будет! S>То есть ты эксперт в нетовских генераторах Rest клиентов? S> Или тебе Рабинович напел? S>Ошибки находятся и исправляются. Без ошибок никто не пишет
Ты правда за дискуссией не следишь. Мой тезис в том, что тут ошибка в подходе, а не в конкретных багах. "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов." — тупиковый путь. Перечитай мои сообщения, там будут обоснования, не хочу повторяться.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pauel, Вы писали:
P>·>Это видимо только ты не понял у кого проблемы. Проблема у Ночного Смотрящего, с которым я тут непосредственно беседую. Именно он перебрал кучу кодогенераторов, плюнул и предложил писать всё ручками. P>Сам подумай, что это значит — кодогенераторы в общей массе отстой. И именно ты топишь за использование тех, которые отстой.
Спорить не буду, ибо не важно это. Мой тезис, что схемогенераторы — ещё более отстой, чем кодогенераторы.
P>>>Если это про OpenApi, то с ним большие проблемы. О чем и речь. P>·>Т.е. твой вариант — не использовать никакой openapi и весь код писать руками, как деды завещали и Ночной Смотрящий делает. Так? Или какую альтернативу ты предлагаешь? P>Очевидно, что не так. Я пишу — использовать проверенную оттестированую либу, но тебе мерещится "писать весь код руками"
Угу. Так используй проверенную оттестированную либу для кодогенерации. Кто запрещает-то?
P>·>Очень даже зависимо. Вручную сделанный openapi проще поддерживать во вменяемом состоянии. P>Как мы выяснили, у OpenAPI проблема не с манифестом, а с кодогенерацией. P>Поскольку кодогенераторы для OpenAPI кривые, шо сабля, то тебе надо точно знать фичи кодогенератора, и избегать лишнего в манифесте P>В противном случае лишняя строчка в манифесте или сломает клиент, или сломает сервер, или просто проигнорится P>И то, и другое, и третье есть проблема
И чем поможет схемогенератор?
P>·>Ты как-то упустил слово _таких_. Этот подход решает вполне определённый класс проблем. Но, ясен пень, не решает все проблемы. P>А раз не решает все, то часть останутся на проде. Гы-гы. Откуда и следует, что нужно тестировать и прод. Например — при обновлении 3rd party зависимостей.
Нет, не следует.
P>>>Соответственно если у тебя есть тесты прода — пусканул после обновления их сервиса, выявил проблемы, и до того, как юзеры проснулись, уже всё пофиксано. P>·>Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление. P> Алё — они поменяли свой сервис глядя в свои тесты. И подломали некоторые запросы твоего сервиса.
Это и лечится SIT.
P>·>И выкатил в прод без тестов интеграции с вами? Так тут проблема в том, что кто-то что-то выкатывает в прод без тестов. P>Это норма, а не проблема. Крупные вендоры апи имеют десятки и сотни тысяч консумеров. Ты для них один из сотен тысяч.
Про conformance tests я уже тоже рассказывал.
P>Например, ты заюзал sendgrid или mailgun. Они трохи обновились. Ты же фанат емейлов и всё такое. И вот после их обновления часть ваших юзеров перестала получать уведомления. Гы-гы. P>Пускаешь тесты прода и видишь, что емейлы таки глючат. Опаньки!
Нормальные вендоры предоставляют средства для тестирования. Ищем для первого упомянутого: https://docs.sendgrid.com/ui/sending-email/email-testing
Те вендоры, которые не могут это обеспечить либо посылаются лесом, либо, если совсем выбора нет, монополисты, требуют очень пристального внимания.
P>>>То есть, вы не смогли промигрировать код на нужную версию яп — всё, большой проект, оло-ло-ло-ло! P>·>Что значит "не смогли"? Тут всё просто. Бюджета нет, проект в состоянии EoL, команду разогнали — никто мигрировать не будет. Ты в большой организации никогда не работал? +100к работников чтобы... P>Тогда это не признак большого проекта, а скорее признак тухлого проекта, который еле держится на плаву.
И что?
P>·>Совершенно верно, и не поспоришь — лучше быть здоровым и богатым, чем больным и бедным. Ну так бери проверенное протестированное решение и в contract-first с openapi, я разрешаю. P>Мы уже выяснили — бредогенераторов для openapi 100500 единиц, и почти все из них или не подходят, или их нельзя использовать
И? В чём твой солюшн-то?
P>Типичный кейс — понадобилась некоторая фича, а кодогенератор не поддерживает, приплызд
Я сам их подпатчивал и даже пулл-реквесты засылал, мелочёвку правда, и их даже мержили, не рокет-сайнс совершенно.
P>>>В лучшем случае, я уже сказал, генератор не нужен. Он необходим только для экспорта АПИ. P>·>Продолжай. Что за экспорт АПИ? И что с результатом экспорта потом делать? P>Экспорт АПИ — это ты предоставляешь АПИ своего сервиса внешним консумерам.
Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут?
P>>>Ты описал типичную картину для OpenAPI, независимо от того, генеришь манифест, или пишешь руками. P>·>Очень даже зависимо. Т.к. цепочка жонглирования становится короче и количество сущностей уменьшается (не нужно писать метаданные, не нужен их парсер и схемогенератор). P> Теоретик? P>1 Тебе надо держать в уме возможности кодогенератора. Заюзал ты ResponseHeaders, а у тебя такое не поддерживается. Гы-гы.
То же и со схемогенератором. Или он у тебя универсальный всемогутер?
P>2 Метаданные парсить не нужно, это типизированый интерфейс, по которому генерить что угодно легко и просто.
А надо-то генерировать не что угодно, а только то, что умеет openapi.
P>3 Вместо схемогенератора у тебя кодогенератор, при чем — два штуки, каждый со своими особенностями, клиент и сервер.
У тебя не просто схемогенератор, а схемогенератор+кодогенератор. Иначе генерить схему без последующей кодогенерации — зря электричество жечь.
Сделать два кодогенератора проще, чем схемогенератор+кодогенератор.
P>·>Что значит "взять"? У тебя оно уже вроде есть, но генерится. P>"Взять" — подставляем вместо spec в твоей форумуле успеха OpenAPI, и проверяем твою гипотезу P>И оказывается, что именно здесь получается бред, который ты сам же и описал.
Так у тебя бреда получается ещё больше.
P>>>Приплызд! P>·>А абсолютно всемогущий безбажный генератор спеки из развешанных метаданных вам бог ниспосылает. Счастливчики, не всем так везёт, вот Ночному Смотрящему и тем погромистам из restapi.moedelo.org не повезло, например. P>С генератором спеки гораздо проще. Кодогенератор это намного более сложная задача. P>Я например писал и то, и другое. Кодогенератор это хтонический ужос по сравнению с генерацией джсон по метаданным.
Спекогенератор без кодогенератора не нужен. Так что задачу создания кодогенератора решать всё равно придётся. Единственно, чем ты можешь парировать, это тем, что решение задачи кодогенератора ты можешь спихнуть на других и всё ещё получить свою зарплату за "успешно" сданный проект.
P>>>Это проблема — пока найдешь нужную комбинацию, вспотеешь. А если у тебя уже готовый проект, то втиснуть него нечто иное не факт, что выйдет. P>·>А сгенерить нечто полезное почему выйдет из произвольно написанного готового проекта на произвольном фреймворке? P>Генерится не из произвольно написаного кода, а из метаданных которые предоставляются либой. Они по своей природе навешиваются на что угодно без проблем.
Я знаю. Только это всё усложняет.
P>>>И тут приходится писать кодогенератор самому, т.к. другого выхода нет. P>·>Так же придётся писать спекогенератор, что Ночной Смотрящий рассуждал 2 года назад: "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов". P>Он пишет про другое — ты внимательно прочитай.
Я прочитал и понял именно так. Если у тебя есть другая интерпретация, выкладывай.
P> компилер говорит тебе, что выхлоп компилируется. А что выхлоп нерабочий или содержит не то, или не содержит того, никакой компилер тебе не подскажет. >> Сделать работающее решение очень просто, именно поэтому "генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера". P>Наоборот — генераторы приходится писать, потому что они в основной массе ни на что не годятся. Берешь генератор кода, и вдруг оказывается, что в генеренном коде нужен хук для инструментирования. P>А его нет. Гы-гы. Надо писать новый генератор, потому что допилить напильником не выходит из за GPL лицензии.
Ну зашли пулл-реквест.
Впрочем, мне не доводилось видеть такого, обычно такие генераторы предоставляют возможность конфигурации кастомнымными шаблонами.
>> На порядок проще, чем придумывать и развешивать метаданные, добавлять дополнительную метаинформацию, обрабатывать всё это дело и пытаться сгенерить хоть что-то полезное из этого, именно поэтому лишь "чисто теоретически я знаю как все таки сделать нормальный генератор". P>Еще раз — не надо придумывать метаданные. Алё, ты вообще читаешь? Берем проверенную либу, закладываемся на её возможности.
Это не я их предлагаю придумывать, а Ночной Смотрящий, ему это и советуй.
P>>>То есть, твоя "доработка" по сложности даст примерно то же, что генерация JSON по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов. P>·>Это неправда. Более того, тебе придётся такой генератор писать в любом случае, если ты хочешь хоть как-то использовать спеку. P>Снова теоретизирования Нам нужно проверить, что схема валидная. Мы берем готовый тул, который умеет слать запросы по такой спеке, и пишем под него тесты. Здесь у нас ровно 0 генеренного кода.
Тесты можно писать проще, без схемы и специальных тулов.
>> Единственное как можно "решить" эту проблему, это сваять какую-нибудь хрень, вывалить сгенерённую спеку клиентам и сказать, что это их проблема что они потом будут с ней делать. Это именно то, что сделали погромисты тут
. P>Ты высек сам себя — по твоей ссылке пример работы бредо кодогенератора. Этот бредогенератор такое нагенерил, что ни руками вычистить, ни внятно использовать нельзя.
Ты читать точно умеешь? https://restapi.moedelo.org/docs — это именно что сгенерённая swagger схема. Которую невозможно ни для чего полезного применить, даже глазками почитать и то проблема, тулзы на ней затыкаются.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты правда за дискуссией не следишь. Мой тезис в том, что тут ошибка в подходе, а не в конкретных багах. "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов." — тупиковый путь. Перечитай мои сообщения, там будут обоснования, не хочу повторяться.
Это было 2 года назад. Есть различные резолверы итд. Все развивается. Тут уже вопросы о полноте описания классов и методов в swagger.
Например по сравнению с wsdl. Проблем с wsdl не было.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>·>Ты правда за дискуссией не следишь. Мой тезис в том, что тут ошибка в подходе, а не в конкретных багах. "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов." — тупиковый путь. Перечитай мои сообщения, там будут обоснования, не хочу повторяться. S> Это было 2 года назад. Есть различные резолверы итд. Все развивается. Тут уже вопросы о полноте описания классов и методов в swagger.
Именно мы эти вопросы и обсуждаем. Вместо того, чтобы просто полно описывать классы и методы напрямую в swagger, приходится "всё развивать" (с нулевым успехом по факту) дополнительную метаинформацию и допиливать и так уже нетривиальный swashbuckle.
S>Например по сравнению с wsdl. Проблем с wsdl не было.
Верно. И поэтому он благополучно скончался.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
S>>Например по сравнению с wsdl. Проблем с wsdl не было. ·>Верно. И поэтому он благополучно скончался.
Это все проблемы с браузерами, а именно JS. На него и было изначально недоделанный swagger настроен со своим недоделанным json.
yaml хоть ввести додумались!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
P>>Сам подумай, что это значит — кодогенераторы в общей массе отстой. И именно ты топишь за использование тех, которые отстой. ·>Спорить не буду, ибо не важно это. Мой тезис, что схемогенераторы — ещё более отстой, чем кодогенераторы.
У тебя нет аргументов.
P>>Очевидно, что не так. Я пишу — использовать проверенную оттестированую либу, но тебе мерещится "писать весь код руками" ·>Угу. Так используй проверенную оттестированную либу для кодогенерации. Кто запрещает-то?
Отсутствие таких в природе с силу принципиальной сложности кодогенерации.
P>>В противном случае лишняя строчка в манифесте или сломает клиент, или сломает сервер, или просто проигнорится P>>И то, и другое, и третье есть проблема ·>И чем поможет схемогенератор?
Генератор схемы это не какая нибудь сложная вещь, легко покрывается тестами, в отличие от кодогенератора.
Когда имплементишь апи, то эту часть и так нужно покрыть тестами, что естественно.
P>>А раз не решает все, то часть останутся на проде. Гы-гы. Откуда и следует, что нужно тестировать и прод. Например — при обновлении 3rd party зависимостей. ·>Нет, не следует.
У тебя снова нет аргументов, поздравляю!
P>>·>Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление. P>> Алё — они поменяли свой сервис глядя в свои тесты. И подломали некоторые запросы твоего сервиса. ·>Это и лечится SIT.
Не лечится. Напомню — у вендора таких как ты 100500 контрактов. Тестировать как их новое апи ведет себя с каждым из консумером они никак не могут.
Максимум, для особых кейсов могут предоставить тестовые инстансы. Но это не гарантирует решение всех проблем.
P>>Это норма, а не проблема. Крупные вендоры апи имеют десятки и сотни тысяч консумеров. Ты для них один из сотен тысяч. ·>Про conformance tests я уже тоже рассказывал.
Ты же не собираешься запускать их на проде. А значит будешь тестировать "юзером".
У них тесты зеленые. А твоя система против их новой версии никогда не работала.
Приплызд.
P>>Пускаешь тесты прода и видишь, что емейлы таки глючат. Опаньки! ·>Нормальные вендоры предоставляют средства для тестирования. Ищем для первого упомянутого: https://docs.sendgrid.com/ui/sending-email/email-testing
Именно такие тесты и нужно пускануть после обновления с их стороны. Альтернатива — "у нас багов нет", это твой любимый вариант.
P>>Тогда это не признак большого проекта, а скорее признак тухлого проекта, который еле держится на плаву. ·>И что?
Ты говоришь про большой проект, а под признаки подходит любой, где нет денег. Например — 1 человек работает вместо команды и кое как справляется, на миграцию денег-времени нет.
То есть, ты просто накидываешь абы что.
P>>Мы уже выяснили — бредогенераторов для openapi 100500 единиц, и почти все из них или не подходят, или их нельзя использовать ·>И? В чём твой солюшн-то?
Я ж сказал — исключить кодогенерацию, оставить генерацию схемы для внешних консумеров, если у них платформа отличная от твоей.
Если такая же — ты им даешь клиент который у тебя готов на этапе создания апи. Напоминаю — описание апи дает нам автоматически и сам клиент.
P>>Типичный кейс — понадобилась некоторая фича, а кодогенератор не поддерживает, приплызд ·>Я сам их подпатчивал и даже пулл-реквесты засылал, мелочёвку правда, и их даже мержили, не рокет-сайнс совершенно.
Именно что мелочевку. А что делать с большими фичами-багами — не ясно.
Обилие кривых кодогенераторов гарантирует затраты времени на выбор подходящего.
P>>Экспорт АПИ — это ты предоставляешь АПИ своего сервиса внешним консумерам. ·>Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут?
Что им надо делать, то и будут.
P>> Теоретик? P>>1 Тебе надо держать в уме возможности кодогенератора. Заюзал ты ResponseHeaders, а у тебя такое не поддерживается. Гы-гы. ·>То же и со схемогенератором. Или он у тебя универсальный всемогутер?
Схемогенератор это вещь намного проще. Типичный разработчик искаропки умеет генерировать json по набору данных, все приложения состоят из такой логики. А вот внятную кодогенерацию сделать — это вещь нетривиальная.
P>>2 Метаданные парсить не нужно, это типизированый интерфейс, по которому генерить что угодно легко и просто. ·>А надо-то генерировать не что угодно, а только то, что умеет openapi.
В слова решил поиграть?
P>>3 Вместо схемогенератора у тебя кодогенератор, при чем — два штуки, каждый со своими особенностями, клиент и сервер. ·>У тебя не просто схемогенератор, а схемогенератор+кодогенератор. Иначе генерить схему без последующей кодогенерации — зря электричество жечь.
Мне нужна генерация схемы + тесты по этой схеме. Тестировать конкретным генереным клиентом в корне неверно.
·>Сделать два кодогенератора проще, чем схемогенератор+кодогенератор.
Нужен только схемогенератор — апи будет тестироваться не абы чем, а конкретным тулом который умеет openapi.
Ты не знаешь ни версию кодогенератора у клиента, ни платформу, ни даже язык программирования.
>>И оказывается, что именно здесь получается бред, который ты сам же и описал. ·>Так у тебя бреда получается ещё больше.
Главное что ты сам себе противоречишь.
P>>Я например писал и то, и другое. Кодогенератор это хтонический ужос по сравнению с генерацией джсон по метаданным. ·>Спекогенератор без кодогенератора не нужен.
Ты так и не сказал, зачем кодогенератор есть уже есть генератор спеки.
P>>Генерится не из произвольно написаного кода, а из метаданных которые предоставляются либой. Они по своей природе навешиваются на что угодно без проблем. ·>Я знаю. Только это всё усложняет.
А я вижу, что облегчают.
P>>Он пишет про другое — ты внимательно прочитай. ·>Я прочитал и понял именно так. Если у тебя есть другая интерпретация, выкладывай.
Он пишет о том, что хороших кодогенератов для клиента не нашли.
P>>А его нет. Гы-гы. Надо писать новый генератор, потому что допилить напильником не выходит из за GPL лицензии. ·>Ну зашли пулл-реквест.
И чем тебе пулл реквест поможет если лицуха GPL ? Такой софт не факт что можно в любой конторе использовать.
P>>Еще раз — не надо придумывать метаданные. Алё, ты вообще читаешь? Берем проверенную либу, закладываемся на её возможности. ·>Это не я их предлагаю придумывать, а Ночной Смотрящий, ему это и советуй.
Это твои домыслы. У него ничего не сказано, либу он берет, или врукопашную чегото делает.
P>>Снова теоретизирования Нам нужно проверить, что схема валидная. Мы берем готовый тул, который умеет слать запросы по такой спеке, и пишем под него тесты. Здесь у нас ровно 0 генеренного кода. ·>Тесты можно писать проще, без схемы и специальных тулов.
Нам нужно не просто абы что абы куда послать, а дать гарантии, что тест посланый согласно спецификации OpenAPI будет понят твоим сервисом.
В противном случае получится так, что тесты зеленые, потому что девелоперы-тестеры намастырили их по записям со стейджа, а у клиента ничо не работает, т.к. он шлет в строгом соответствии со спекой.
P>>Ты высек сам себя — по твоей ссылке пример работы бредо кодогенератора. Этот бредогенератор такое нагенерил, что ни руками вычистить, ни внятно использовать нельзя. ·>Ты читать точно умеешь? https://restapi.moedelo.org/docs — это именно что сгенерённая swagger схема. Которую невозможно ни для чего полезного применить, даже глазками почитать и то проблема, тулзы на ней затыкаются.
1. есть схема
2. какие то кодогенераторы с ней не справляются
С чего ты взял, что она генерированая? Подробнее. Я видел и бОльшие простыни, созданные вручную.
Здравствуйте, Pauel, Вы писали:
P>>>Очевидно, что не так. Я пишу — использовать проверенную оттестированую либу, но тебе мерещится "писать весь код руками" P>·>Угу. Так используй проверенную оттестированную либу для кодогенерации. Кто запрещает-то? P>Отсутствие таких в природе с силу принципиальной сложности кодогенерации.
Я ими пользовался. Работает хорошо, если схема вменяемая.
P>·>И чем поможет схемогенератор? P>Генератор схемы это не какая нибудь сложная вещь, легко покрывается тестами, в отличие от кодогенератора. P>Когда имплементишь апи, то эту часть и так нужно покрыть тестами, что естественно.
Вообще элементарно. Результат кодогенерации очень надёжно тестируется компилятором.
P>>>А раз не решает все, то часть останутся на проде. Гы-гы. Откуда и следует, что нужно тестировать и прод. Например — при обновлении 3rd party зависимостей. P>·>Нет, не следует. P>У тебя снова нет аргументов, поздравляю!
Ну не следует и всё тут. Достаточно тестировать тестовое окружение.
P>>>·>Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление. P>>> Алё — они поменяли свой сервис глядя в свои тесты. И подломали некоторые запросы твоего сервиса. P>·>Это и лечится SIT. P>Не лечится. Напомню — у вендора таких как ты 100500 контрактов. Тестировать как их новое апи ведет себя с каждым из консумером они никак не могут. P>Максимум, для особых кейсов могут предоставить тестовые инстансы.
Этого достаточно.
P>Но это не гарантирует решение всех проблем.
А что гарантирует решение всех проблем?
P>>>Это норма, а не проблема. Крупные вендоры апи имеют десятки и сотни тысяч консумеров. Ты для них один из сотен тысяч. P>·>Про conformance tests я уже тоже рассказывал. P>Ты же не собираешься запускать их на проде. А значит будешь тестировать "юзером".
тестовым юзером.
P>>>Пускаешь тесты прода и видишь, что емейлы таки глючат. Опаньки! P>·>Нормальные вендоры предоставляют средства для тестирования. Ищем для первого упомянутого: https://docs.sendgrid.com/ui/sending-email/email-testing P>Именно такие тесты и нужно пускануть после обновления с их стороны. Альтернатива — "у нас багов нет", это твой любимый вариант.
Только это не прод, а тест.
P>>>Тогда это не признак большого проекта, а скорее признак тухлого проекта, который еле держится на плаву. P>·>И что? P>Ты говоришь про большой проект, а под признаки подходит любой, где нет денег. Например — 1 человек работает вместо команды и кое как справляется, на миграцию денег-времени нет. Вот только что свежачок
от Ночного Смотрящего: "уже год пытаемся с 3.1 слезть, но пока только отдельные сервисы переползли". Вот и расскажи ему какой у него тухляк и денег у них нет и научи его жизни.
P>То есть, ты просто накидываешь абы что.
Это не накидывание, а реальность.
P>>>Мы уже выяснили — бредогенераторов для openapi 100500 единиц, и почти все из них или не подходят, или их нельзя использовать P>·>И? В чём твой солюшн-то? P>Я ж сказал — исключить кодогенерацию, оставить генерацию схемы для внешних консумеров, если у них платформа отличная от твоей.
Ты расскажи. Зачем схема внешним консьюмерам?
P>Если такая же — ты им даешь клиент который у тебя готов на этапе создания апи. Напоминаю — описание апи дает нам автоматически и сам клиент.
Не распарсил. Что автоматически?
P>>>Типичный кейс — понадобилась некоторая фича, а кодогенератор не поддерживает, приплызд P>·>Я сам их подпатчивал и даже пулл-реквесты засылал, мелочёвку правда, и их даже мержили, не рокет-сайнс совершенно. P>Именно что мелочевку. А что делать с большими фичами-багами — не ясно. P>Обилие кривых кодогенераторов гарантирует затраты времени на выбор подходящего.
Брад какой — "слишком много выбора, значит плохо". Ну не выбирай, напиши свой. Это вполне под силу даже миддлу.
P>>>Экспорт АПИ — это ты предоставляешь АПИ своего сервиса внешним консумерам. P>·>Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут? P>Что им надо делать, то и будут.
Ясно. Проблемы консьюмеров шерифа не волнуют. ЧТД.
P>>>1 Тебе надо держать в уме возможности кодогенератора. Заюзал ты ResponseHeaders, а у тебя такое не поддерживается. Гы-гы. P>·>То же и со схемогенератором. Или он у тебя универсальный всемогутер? P>Схемогенератор это вещь намного проще. Типичный разработчик искаропки умеет генерировать json по набору данных, все приложения состоят из такой логики. А вот внятную кодогенерацию сделать — это вещь нетривиальная.
Гораздо проще. Валидировать сгенерённый код можно компилятором. Валидировать генерённый json и по каким критериям — не знаю как.
P>>>2 Метаданные парсить не нужно, это типизированый интерфейс, по которому генерить что угодно легко и просто. P>·>А надо-то генерировать не что угодно, а только то, что умеет openapi. P>В слова решил поиграть?
Нет. Пытаюсь достучаться. Ты должен писать такие метаданные и такой интерфейс, который хорошо ложится в openapi. Иначе то что нагенерится будет коту под хвост.
P>>>3 Вместо схемогенератора у тебя кодогенератор, при чем — два штуки, каждый со своими особенностями, клиент и сервер. P>·>У тебя не просто схемогенератор, а схемогенератор+кодогенератор. Иначе генерить схему без последующей кодогенерации — зря электричество жечь. P>Мне нужна генерация схемы + тесты по этой схеме. Тестировать конкретным генереным клиентом в корне неверно.
Ты так и не рассказал зачем нужная эта схема.
P>·>Сделать два кодогенератора проще, чем схемогенератор+кодогенератор. P>Нужен только схемогенератор — апи будет тестироваться не абы чем, а конкретным тулом который умеет openapi.
Зачем? Чтобы что?
P>Ты не знаешь ни версию кодогенератора у клиента, ни платформу, ни даже язык программирования.
Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.
P>>>Я например писал и то, и другое. Кодогенератор это хтонический ужос по сравнению с генерацией джсон по метаданным. P>·>Спекогенератор без кодогенератора не нужен. P>Ты так и не сказал, зачем кодогенератор есть уже есть генератор спеки.
Сказал уже много раз. Ты просто не читаешь. Чтобы сгенерированную спеку можно было использовать с пользой.
P>>>Он пишет про другое — ты внимательно прочитай. P>·>Я прочитал и понял именно так. Если у тебя есть другая интерпретация, выкладывай. P>Ну так дай ссылку дай на сообщение, где НС это утверждает. Насколько я понимаю, ты искусно вырезал часть его утверждения. Вот
Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.
Т.е. чтобы сгенерённую спеку можно было использовать клиентам, требуется дополнительная метаинформация и допиливание схемогенератора. И это всё теоретически.
P>>>А его нет. Гы-гы. Надо писать новый генератор, потому что допилить напильником не выходит из за GPL лицензии. P>·>Ну зашли пулл-реквест. P>И чем тебе пулл реквест поможет если лицуха GPL ? Такой софт не факт что можно в любой конторе использовать.
Имя софта в студию. Или ты теоретег?
P>>>Еще раз — не надо придумывать метаданные. Алё, ты вообще читаешь? Берем проверенную либу, закладываемся на её возможности. P>·>Это не я их предлагаю придумывать, а Ночной Смотрящий, ему это и советуй. P>Это твои домыслы. У него ничего не сказано, либу он берет, или врукопашную чегото делает.
Его цитаты: "пришли к выводу что писать клиентов нужно руками". "добавления в swagger.json дополнительной метаинформации".
P>>>Снова теоретизирования Нам нужно проверить, что схема валидная. Мы берем готовый тул, который умеет слать запросы по такой спеке, и пишем под него тесты. Здесь у нас ровно 0 генеренного кода. P>·>Тесты можно писать проще, без схемы и специальных тулов. P> Нам нужно не просто абы что абы куда послать, а дать гарантии, что тест посланый согласно спецификации OpenAPI будет понят твоим сервисом.
Зачем? Если эту спецификацию ни для чего более использовать не выходит?
P>В противном случае получится так, что тесты зеленые, потому что девелоперы-тестеры намастырили их по записям со стейджа, а у клиента ничо не работает, т.к. он шлет в строгом соответствии со спекой.
Хорошо, но уже лучше. Осталось тебе понять, что не обязательно для этого генерить спеку.
P>>>Ты высек сам себя — по твоей ссылке пример работы бредо кодогенератора. Этот бредогенератор такое нагенерил, что ни руками вычистить, ни внятно использовать нельзя. P>·>Ты читать точно умеешь? https://restapi.moedelo.org/docs — это именно что сгенерённая swagger схема. Которую невозможно ни для чего полезного применить, даже глазками почитать и то проблема, тулзы на ней затыкаются. P>1. есть схема P>2. какие то кодогенераторы с ней не справляются
Да мало кто справился. В этом и дело. Сделано на от*бись.
P>С чего ты взял, что она генерированая? Подробнее. Я видел и бОльшие простыни, созданные вручную.
У тебя есть сомнения?! Подскажи мне вещества, которые позволят человеку написать "Moedelo.DocumentsRegister.Api.Models.Dto.ApiDataResponseDto`1[[System.Collections.Generic.List`1[[Moedelo.DocumentsRegister.Api.Models.Dto.DocumentRegisterDto, Moedelo.DocumentsRegister.Api, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]" в однострочный полутрамеговый json.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>Отсутствие таких в природе с силу принципиальной сложности кодогенерации. ·>Я ими пользовался. Работает хорошо, если схема вменяемая.
Теоретически — найти можно. Но так далеко не на любой платформе и яп.
P>>Когда имплементишь апи, то эту часть и так нужно покрыть тестами, что естественно. ·>Вообще элементарно. Результат кодогенерации очень надёжно тестируется компилятором.
Детский сад. Как компилятор поможет, если генератор "забыл" кое какие методы сгенерировать? Компилится, значит круто?
Вообще то нет — нужны тесты.
P>>·>Нет, не следует. P>>У тебя снова нет аргументов, поздравляю! ·>Ну не следует и всё тут. Достаточно тестировать тестовое окружение.
Недостаточно. В проде состояние системы будет другим. Data complexity никто не отменял. Если, теоретически, ты можешь 1 в 1 создать копию окружения, до единого бита, то полную копию данных точно не выйдет создать.
Но вот по факту такого не бывает, разве что для небольших приложений.
P>>Максимум, для особых кейсов могут предоставить тестовые инстансы. ·>Этого достаточно.
У тебя снова нет аргументов.
P>>Но это не гарантирует решение всех проблем. ·>А что гарантирует решение всех проблем?
Тесты на целевой системе, то есть, проде.
P>>Ты же не собираешься запускать их на проде. А значит будешь тестировать "юзером". ·>тестовым юзером.
Если на проде не тестируешь, то всегда огромный шанс, что багу первым найдет юзер, напорется, по разными причинам, например — никогда не бывает 100% соответствия стейджинга и прода.
·>Вот только что свежачок
от Ночного Смотрящего: "уже год пытаемся с 3.1 слезть, но пока только отдельные сервисы переползли". Вот и расскажи ему какой у него тухляк и денег у них нет и научи его жизни.
Само по себе три компилера-платформы на проекте может быть и на малом проекте, и на большом.
P>>Я ж сказал — исключить кодогенерацию, оставить генерацию схемы для внешних консумеров, если у них платформа отличная от твоей. ·>Ты расскажи. Зачем схема внешним консьюмерам?
Они это апи покупают, делают вызовы.
P>>Если такая же — ты им даешь клиент который у тебя готов на этапе создания апи. Напоминаю — описание апи дает нам автоматически и сам клиент. ·>Не распарсил. Что автоматически?
Очень просто — описываешь интерфейс, обычный, либа сама делает из него клиент. Для внутреннего использования кодогенерация исключается.
P>>Обилие кривых кодогенераторов гарантирует затраты времени на выбор подходящего. ·>Брад какой — "слишком много выбора, значит плохо". Ну не выбирай, напиши свой. Это вполне под силу даже миддлу.
Не под силу, в том то и дело. Хороший кодогенератор это большие трудозатраты. У меня в мейнтенансе два таких.
P>>·>Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут? P>>Что им надо делать, то и будут. ·>Ясно. Проблемы консьюмеров шерифа не волнуют. ЧТД.
Ты бы лучше мысли формулировал. Консумеры покупают апи, вызывают, оплачивают вызовы и тд.
P>>Схемогенератор это вещь намного проще. Типичный разработчик искаропки умеет генерировать json по набору данных, все приложения состоят из такой логики. А вот внятную кодогенерацию сделать — это вещь нетривиальная. ·>Гораздо проще. Валидировать сгенерённый код можно компилятором. Валидировать генерённый json и по каким критериям — не знаю как.
Детский сад — как компилер проверит, что есть два метода, которых быть не должно ? Или что нет двух методов, которые быть должны. Код то компилится!
·>Нет. Пытаюсь достучаться. Ты должен писать такие метаданные и такой интерфейс, который хорошо ложится в openapi. Иначе то что нагенерится будет коту под хвост.
Для этого есть тесты апи, которые работают через openapi тул, безо всякой кодогенерации специального клиента.
P>>Мне нужна генерация схемы + тесты по этой схеме. Тестировать конкретным генереным клиентом в корне неверно. ·>Ты так и не рассказал зачем нужная эта схема.
По моему ты сейчас юродствуешь. Схема нужна внешним консумерам, что бы они могли вызывать твой сервис.
P>>·>Сделать два кодогенератора проще, чем схемогенератор+кодогенератор. P>>Нужен только схемогенератор — апи будет тестироваться не абы чем, а конкретным тулом который умеет openapi. ·>Зачем? Чтобы что?
Что бы убедиться, что апи работает согласно требованиям.
P>>Ты не знаешь ни версию кодогенератора у клиента, ни платформу, ни даже язык программирования. ·>Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.
Попробовали, получили отстой. Дальше что?
P>>Ты так и не сказал, зачем кодогенератор есть уже есть генератор спеки. ·>Сказал уже много раз. Ты просто не читаешь. Чтобы сгенерированную спеку можно было использовать с пользой.
Точнее — ни разу.
P>>Ну так дай ссылку дай на сообщение, где НС это утверждает. Насколько я понимаю, ты искусно вырезал часть его утверждения. ·>Вот
Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.
·>Т.е. чтобы сгенерённую спеку можно было использовать клиентам, требуется дополнительная метаинформация и допиливание схемогенератора. И это всё теоретически.
То есть, он утверждает, что трудно сделать хороший кодогенератор, т.к. отсутствует метадата по семантике
Как ты этот вопрос обойдешь ручным набиванием схемы?
P>>И чем тебе пулл реквест поможет если лицуха GPL ? Такой софт не факт что можно в любой конторе использовать. ·>Имя софта в студию. Или ты теоретег?
Да полно таких и не только проблем. Мы делали про openapi большой ресёрч, сравнивали состояние дел в разных кодогенераторах.
P>>Это твои домыслы. У него ничего не сказано, либу он берет, или врукопашную чегото делает. ·>Его цитаты: "пришли к выводу что писать клиентов нужно руками". "добавления в swagger.json дополнительной метаинформации".
Именно. Раз кодогенератор не умеет в семантику, а он не умеет, т.к. в манифесте такой фичи нет, то остаётся один вариант — писать руками.
P>> Нам нужно не просто абы что абы куда послать, а дать гарантии, что тест посланый согласно спецификации OpenAPI будет понят твоим сервисом. ·>Зачем? Если эту спецификацию ни для чего более использовать не выходит?
Эта спека нужна для того, что бы люди могли твой сервис использовать.
P>>1. есть схема P>>2. какие то кодогенераторы с ней не справляются ·>Да мало кто справился. В этом и дело. Сделано на от*бись.
Вот это и есть главная причина.
P>>С чего ты взял, что она генерированая? Подробнее. Я видел и бОльшие простыни, созданные вручную. ·>У тебя есть сомнения?! Подскажи мне вещества, которые позволят человеку написать "Moedelo.DocumentsRegister.Api.Models.Dto.ApiDataResponseDto`1[[System.Collections.Generic.List`1[[Moedelo.DocumentsRegister.Api.Models.Dto.DocumentRegisterDto, Moedelo.DocumentsRegister.Api, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]" в однострочный полутрамеговый json.
Не в курсе, может взяли смержили кусочки рукописных файлов, да слегка обработали
