Комментарии 11
Просто буквально с месяц назад писал генератор TS интерфейсов из Java типов. Я знаю, что есть готовые. Но мне, как обычно, не подходили по тем или иным причинам. Поэтому пошел посмотреть на исходники.
И что же я вижу — генерация стрингов… Ну так не спортивно. Надо же AST генерировать. В TS все есть для этого.
Его же можно потом трансформировать еще, можно просто распечатать в строку. Но будет медленней конечно. Зато более поддерживаемо.
Момент второй: конвертор генерирует не в строку, а в промежуточные конструкции, которые ближе к OpenAPI, чем к TypeScript. Генерация в TypeScript сделана по принципу адаптера — то есть расширение. При желании можно добавить адаптер для любого другого языка, с любой структурой. И, собственно, там может не быть никаких AST. И да, я утверждаю, что генерация в строку самая простая и самая эффективная.
Я имел ввиду, что этот адаптер генерирует строку. Дело не в спорте. Если завтра выйдет новая версия TS, то вам 1. придется как-то проверять, что ваш генератор генерирует все еще корректный код 2. в случае проблем исправлять В случае использования родного TS AST вы получите часть проверок автоматически, ну и из AST вы всегда получите корректный код, потому что это гарантирует сам TS. Показать не могу это не опен сорс. И вообще это Java. OAS-спецификацию не могу прокрутить у меня на входе Java класс как объект Class<?>, на выходе AST TS модуля (точнее декларации). Чтобы посмотреть на что это похоже посмотрите это https://ts-ast-viewer.com/#
Если завтра выйдет новая версия TS, то вам 1. придется как-то проверять. придется как-то проверять, что ваш генератор генерирует все еще корректный код
Даже если такие маловероятные кейсы сыграют, не будет большой проблемой дождаться обновления (TS не обновляется принудительно ночью, и всегда можно откатиться). А решение не будет настолько сложным, чтобы окупить оверхед на создание AST-конвертора.
В конце концов, если реально это станет необходимым — тогда и появится повод задуматься о конвертации через AST.
Простите, а можно "заказать" статью для тех кто попроще? :) Какой-нибудь Get Started с созданием трёх роутов на Express и можно сравнение с чем-нибудь типа Yup / Joi и выводом типов из этих валидаторов. Потому что я так и не понял что описывает текущая статья — внутреннее устройство, или внешнее использование, генерирует она только интерфейсы или и рабочий код тоже.
Ну а вообще выглядит круто, надеюсь, запала хватит на поддержку своего детища!
Насчет Get Started — я думал об этом. В планах создание Pipe-валидатора для NestJS (он работает как надстройка над Express) и простой HowTo на 3-4 минуты чтения. Честно говоря, мне было очень тяжело писать эту статью потому что я не понимал ЦА, и просто выложил все до кучи.
А вот с Yup / Joi сравнение вряд ли будет корректным, т.к. это разные инструменты, которые используются в разных подходах. Если нужно поднять бэкенд средней сложности по-быстрому, и не блокировать команду, то OpenAPI вам сто лет и не сдался. И другое дело, если у вас намечается Enterprise, УЖЕ есть спецификация (или очевидна ее необходимость) и любая задача проходит через проектирование.
ЦА разная, есть и новички, и старички, среднячки. Я сейчас в стадии крудошлёпства и в ноябре-деабре смотрел как раз тему OpenAPI, Swagger и прочего, но не нашёл той нитки, по которой бы смог понять что это за технологии, где и как используются. В том числе, глава отвечающая на вопрос "Почему?" про "Если нужно поднять бэкенд средней сложности по-быстрому, и не блокировать команду, то OpenAPI вам сто лет и не сдался" может быть, наверное, отличной для Get Started.
Ну и мне кажется, что кодогенерация нужна везде, просто надо из интерпрайз-решений не тащить оверхед
Кодогенерация из OpenAPI v3 (aka Swagger 3) в TypeScript и не только