LINUX.ORG.RU

История изменений

Исправление static_lab, (текущая версия) :

А вычислить число Ху?

Такое бывает нужно очень редко. Тем более, что более если что-то всё равно вычисляется на бекенде, то лучше там это и вычислять, дабы не создать однажды разные алгоритмы расчёта.

А структуры которые гоняются туда-сюда?

Потому что придётся заморочиться, сделать монореп с shared-библиотекой, в которой хранить структуры апишки и функции валидации. Далее нужно, чтобы DTO, которыми обмениваются бек и фронт правильно типизировали эти данные и натравливали на них нужные валидаторы. И тут заморочка в том, что сами по себе JSON-объекты, которыми обмениваются фронт и бек, не типизированы. То есть эти DTO в API-слое нужно будет правильно типизировать и валидировать вручную или полуавтоматически.

Например, Nest.js и TypeORM используют class-validator и class-transformer. Там относительно прозрачно (хотя слышал, что class-transformer — довольно капризная штука). Значит нужно будет затащить все DTO в shared, а затем прикрутить обе библиотеки к фронтенду.

Однако есть такая заморочка, что на фронтенде чаще всего будет нужна валидация без отправки на сервер. И вот здесь могут быть трудности с интеграцией этих библиотек с фронтендным фреймворком. Angular использует свою библиотеку для работы с формами и их валидацией (вот как раз, где магазин игрушек выходит боком), а для Vue нужны объекты со своими обсерверами, а не те, которые создаёт class-transformer.

Если же в дополнение к Vue (или React) взять Nuxt.js (Next.js), то всё становится ещё веселее из-за появления дополнительного слоя со своими заморочками.

Исходная версия static_lab, :

А структуры которые гоняются туда-сюда?

Потому что придётся заморочиться, сделать монореп с shared-библиотекой, в которой хранить структуры апишки и функции валидации. Далее нужно, чтобы DTO, которыми обмениваются бек и фронт правильно типизировали эти данные и натравливали на них нужные валидаторы. И тут заморочка в том, что сами по себе JSON-объекты, которыми обмениваются фронт и бек, не типизированы. То есть эти DTO в API-слое нужно будет правильно типизировать и валидировать вручную или полуавтоматически.

Например, Nest.js и TypeORM используют class-validator и class-transformer. Там относительно прозрачно (хотя слышал, что class-transformer — довольно капризная штука). Значит нужно будет затащить все DTO в shared, а затем прикрутить обе библиотеки к фронтенду.

Однако есть такая заморочка, что на фронтенде чаще всего будет нужна валидация без отправки на сервер. И вот здесь могут быть трудности с интеграцией этих библиотек с фронтендным фреймворком. Angular использует свою библиотеку для работы с формами и их валидацией (вот как раз, где магазин игрушек выходит боком), а для Vue нужны объекты со своими обсерверами, а не те, которые создаёт class-transformer.

Если же в дополнение к Vue (или React) взять Nuxt.js (Next.js), то всё становится ещё веселее из-за появления дополнительного слоя со своими заморочками.