Генерация кода валидации из спецификации OpenAPI: как мы синхронизировали валидаторы данных между бэкендом и фронтендом

[vagon333]

Так, так, так, довольно потираю руки.
У нас несколько иная задача, но общий подход похожий: пытаемся автоматизировать поддержку API.
В нашем случае в базе данных хранится структура API и нужно сгенерить Swagger.

Случайно не встречались с решением, которое на базе структуры данных в JSON генерит схему для Swagger и целиком Swagger версии 3.х?

[jarick]

Встречались) chatgpt отлично это умеет делать.

[olku]

О какой версии OpenAPI идет речь в статье? 3.1?

[jarick]

Конкретно мы у себя используем 3.0.1 версию. Но вообще кажется, что статья подходит для любой третий версии OpenAPI.

[olku]

3.1 и 3.0 различаются поддержкой JSON Schema, которая применяется для валидации.

[GulDmitry]

Как при таком подходе дела обстоят с более комплексной валидацией? Например между полями, одна дата меньше другой, запрет будущих дат, порог сумм и т.д. Существуют расширения, но их реализация полностью кастомная. К тому же не понятно какой именно слой валидации покрывает это решение, я бы условно разделил их на валидацию запроса (типы и пороги), сервисная/доменная (бизнес логика), впрочем домен всё равно должен всё перепроверить. В мечтах хотелось бы изоморфно описать всё в одном формате.

[jarick]

Само решение подразумевает, что у вас есть кастомные валидаторы и кастомные правила валидации. Иначе в нём нет никакого смысла берёте Orval и там всё из коробки работает. На счёт того, как вы будете домен описывать, тут уже всё индивидуально. Нам хватает связки formik плюс yup, возможно вам нужно, что-то более многослойное. Вообщем без знания конкретных вводных очень тяжело что-то посоветовать.

[meonsou]

Мб я плохо читал, но не понял зачем нужен Yup. Почему не жсон схема?

[jarick]

Потому что с yup/zod и прочими гораздо удобнее работать. Начиная вопроса расширения валидаторов, написания кастомных правил валилации и заканчивая поддержкой typescript-a из коробки.