C ESM весь инструментарий действительно работает. Но посыл был про то, что ESM открывает дорогу для разработки вне зависимости от среды исполнения, опуская шаги транспиляции и компиляции. Для типизации в этом случае также можно использовать typescript, но уже в ручную описывая d.ts. Или же использовать jsDoc.
P.S. Очевидно, что все скрипты подключаются через тэг script, но мы используем сборщики для этих целей и не пишем это руками.
Я не писал про автоматизацию, только про генерацию)) Для генерации нужна основа, поэтому контракты для этого нужно хранить в кодовой базе. Но я бы не стал их писать самостоятельно, так как не фронты делают ручки.
К сожалению, такова реальность, что именно на фронте пользователи ловят ошибки, поэтому и летит все в сторону фронта. Опять же, если нет грамотного процесса разбора багов.
И я с вами соглашусь, что единственный способ сразу отловить ошибки из-за расхождения контракта - это runtime-валидация с грамотным пользовательским интерфейсом, который сразу отобразит причину.
Наверное стоило отметить, что я все это рассматриваю в контексте React'а, а там из MVC только View. Поэтому деление на слои также идет через компоненты, а подходы уже определяют участники команды.
В хорошем рабочем процессе, контракты обновляются на системном анализе продуктовой или технологической задачи. Все контракты должны быть согласованы разработчиками бэка и фронта до перехода в разработку.
Но бывает так, что системный анализ не предусмотрен штатом сотрудников, тогда за контракты отвечают разработчики бэкенда. Хорошим тоном будет согласовывать контракты при разработке бэкенда с фронтом, но и этого может не быть.
Если согласования контрактов нет, то фронт должны уведомить об изменениях.
Но бывала у меня практика, когда обновленный бэк просто проезжал дальше. Тут уже остается уповать на QA.
Чтобы наверняка узнать на фронте, что контракт поменялся, а вам об этом не сообщили, нужно использовать проверку runtime-типов.
Хорошие вопросы, спасибо! Боюсь, что я не смогу полностью на них ответить, но постараюсь.
По первому вопросу у меня есть опыт в двух вариациях:
Когда контракты ручками с помощью swagger-editor составляют системные аналитики и они хранятся в гите.
Когда контракты генерируют бэкенд-разработчики.
И ответ на второй вопрос также будет в двух вариациях:
Когда контракты готовят системные аналитики, то они ссылаются на них в документации реализуемых фич. А системную документацию согласовывают с разработчиками.
Когда контракты генерируются бэкенд-разработчиками, они также должны крепится к задаче на фронт.
На практике и тот и другой вариант зависит только от того, насколько хорошо работают процессы в команде. Например, первый вариант в одной команде у меня не вызывает никаких проблем, а второй вариант в другой еще как вызывает, так как я постоянно бьюсь с предоставлением и содержанием этих контрактов.
И да, когда контракт обновляется нужно клиент генерировать заново.
@meonsou приветсвую! Я, кстати, не слышал, что генерацию API встраивают в pipeline. Технически это вопросов не вызывает. И да, в этом варианте, если контракт будет изменен, пайплайн упадет, если не будет сделано необходимых изменений на фронте. Таким образом это представляется дополнительной проверкой при деплое, но клиент все равно нужно генерировать руками для разработки или я не правильно вас понял?
C ESM весь инструментарий действительно работает. Но посыл был про то, что ESM открывает дорогу для разработки вне зависимости от среды исполнения, опуская шаги транспиляции и компиляции. Для типизации в этом случае также можно использовать typescript, но уже в ручную описывая d.ts. Или же использовать jsDoc.
P.S. Очевидно, что все скрипты подключаются через тэг script, но мы используем сборщики для этих целей и не пишем это руками.
Я не писал про автоматизацию, только про генерацию)) Для генерации нужна основа, поэтому контракты для этого нужно хранить в кодовой базе. Но я бы не стал их писать самостоятельно, так как не фронты делают ручки.
К сожалению, такова реальность, что именно на фронте пользователи ловят ошибки, поэтому и летит все в сторону фронта. Опять же, если нет грамотного процесса разбора багов.
И я с вами соглашусь, что единственный способ сразу отловить ошибки из-за расхождения контракта - это runtime-валидация с грамотным пользовательским интерфейсом, который сразу отобразит причину.
Наверное стоило отметить, что я все это рассматриваю в контексте React'а, а там из MVC только View. Поэтому деление на слои также идет через компоненты, а подходы уже определяют участники команды.
В хорошем рабочем процессе, контракты обновляются на системном анализе продуктовой или технологической задачи. Все контракты должны быть согласованы разработчиками бэка и фронта до перехода в разработку.
Но бывает так, что системный анализ не предусмотрен штатом сотрудников, тогда за контракты отвечают разработчики бэкенда. Хорошим тоном будет согласовывать контракты при разработке бэкенда с фронтом, но и этого может не быть.
Если согласования контрактов нет, то фронт должны уведомить об изменениях.
Но бывала у меня практика, когда обновленный бэк просто проезжал дальше. Тут уже остается уповать на QA.
Чтобы наверняка узнать на фронте, что контракт поменялся, а вам об этом не сообщили, нужно использовать проверку runtime-типов.
Хорошие вопросы, спасибо! Боюсь, что я не смогу полностью на них ответить, но постараюсь.
По первому вопросу у меня есть опыт в двух вариациях:
Когда контракты ручками с помощью swagger-editor составляют системные аналитики и они хранятся в гите.
Когда контракты генерируют бэкенд-разработчики.
И ответ на второй вопрос также будет в двух вариациях:
Когда контракты готовят системные аналитики, то они ссылаются на них в документации реализуемых фич. А системную документацию согласовывают с разработчиками.
Когда контракты генерируются бэкенд-разработчиками, они также должны крепится к задаче на фронт.
На практике и тот и другой вариант зависит только от того, насколько хорошо работают процессы в команде. Например, первый вариант в одной команде у меня не вызывает никаких проблем, а второй вариант в другой еще как вызывает, так как я постоянно бьюсь с предоставлением и содержанием этих контрактов.
И да, когда контракт обновляется нужно клиент генерировать заново.
@meonsou приветсвую! Я, кстати, не слышал, что генерацию API встраивают в pipeline. Технически это вопросов не вызывает. И да, в этом варианте, если контракт будет изменен, пайплайн упадет, если не будет сделано необходимых изменений на фронте. Таким образом это представляется дополнительной проверкой при деплое, но клиент все равно нужно генерировать руками для разработки или я не правильно вас понял?
Спасибо за комменатрий!
У меня была мысль провести сравнение с nswag, который мы использовали до этого, но статья была бы очень огромной.
Возможно, что я все же проведу, какой-то сравнительный анализ и Ваш генератор тоже обязательно опробую)