Телеграмм чат группы nest

Andrey Melikhov in NestJS — русскоязычное сообщество

10:05пожаловаться #1

AM

Dilame Bowzee

Блин, я вот по прежнему понять не могу, неужели монорепа в виде фронт+бэк это норм?
Ну что там шарить можно?

Если это валидационные DTO, то это нарушение принципа Single source of truth. Валидацией должен заниматься бэк.
Если это graphql схема, то она замечательно интроспектится удалённо

Можно шарить DTO между фронтом и беком, со стороны фронта — DTO для preload state, со стороны бэка — DTO респонса апишек. Это контракты, контракты можно и правильно шарить

10:09пожаловаться #2

V

Можно шарить DTO между фронтом и беком, со стороны фронта — DTO для preload state, со стороны бэка — DTO респонса апишек. Это контракты, контракты можно и правильно шарить

А какие есть варианты, если бек и фронт не в монорепе? Я знаю только один адекватный способ, на фронте парсить опен схему от свагера и по ней генератор интерфейсы.

Andrey Melikhov in NestJS — русскоязычное сообщество

10:12пожаловаться #3

AM

Valentin

А какие есть варианты, если бек и фронт не в монорепе? Я знаю только один адекватный способ, на фронте парсить опен схему от свагера и по ней генератор интерфейсы.

Положить контракт в отдельную репу, например, и шарить её

Alex Konstantinov in NestJS — русскоязычное сообщество

10:14пожаловаться #4

AK

Можно шарить DTO между фронтом и беком, со стороны фронта — DTO для preload state, со стороны бэка — DTO респонса апишек. Это контракты, контракты можно и правильно шарить

Я думал, что контракт это graphql схема, grpc схема, wsdl, но никак не DTO

Andrey Melikhov in NestJS — русскоязычное сообщество

10:14пожаловаться #5

AM

Alex Konstantinov

Я думал, что контракт это graphql схема, grpc схема, wsdl, но никак не DTO

Контракт — это интерфейсы и DTO

10:15пожаловаться #6

V

Положить контракт в отдельную репу, например, и шарить её

А все изменения через версионирование репы. Хм

Andrey Melikhov in NestJS — русскоязычное сообщество

10:15пожаловаться #7

AM

Valentin

А все изменения через версионирование репы. Хм

Да, такое часто делают, когда API и клиентом занимаются разные команды

10:16пожаловаться #8

DB

Контракт — это интерфейсы и DTO

Если DTO это просто интерфейс, то его в принципе можно шарить. Но по крайней мере в несте его предлагают приправлять валидациями. И вот тут уже не понятно, стоит ли тащить это на фронт

10:17пожаловаться #9

V

Да да. Все логично и явно

Andrey Melikhov in NestJS — русскоязычное сообщество

10:17пожаловаться #10

AM

Но конечно если держать клиент и сервер в разных репах, то несколько нивелируется смысл писать сервер на ноде, у нас пропадает весь кайф

Илья | 😶 in NestJS — русскоязычное сообщество

10:17пожаловаться #11

И

Положить контракт в отдельную репу, например, и шарить её

зачем напомнил...
Нужно тайпинги связать с ангуляром, а я опять опечалился :(

10:17пожаловаться #12

V

Но конечно если держать клиент и сервер в разных репах, то несколько нивелируется смысл писать сервер на ноде, у нас пропадает весь кайф

?

Andrey Melikhov in NestJS — русскоязычное сообщество

10:17пожаловаться #13

AM

Dilame Bowzee

Если DTO это просто интерфейс, то его в принципе можно шарить. Но по крайней мере в несте его предлагают приправлять валидациями. И вот тут уже не понятно, стоит ли тащить это на фронт

да, class-validator на фронт тащить не хочется. но можно и без него :)

10:17пожаловаться #14

DB

да, class-validator на фронт тащить не хочется. но можно и без него :)

ну а как валидировать без него?) Нест предлагает валидацию только через DTO

Andrey Melikhov in NestJS — русскоязычное сообщество

10:18пожаловаться #15

AM

Dilame Bowzee

ну а как валидировать без него?) Нест предлагает валидацию только через DTO

неправда, просто нест дружит с class-validator из коробки, но валидационные пайпы ты можешь писать любые

Andrey Melikhov in NestJS — русскоязычное сообщество

10:18пожаловаться #16

AM

Valentin

?

Нода не лучшее решение для работы с данными, писать бэки на ней имеет смысл только именно как фронт-бэки, bff. Тут сразу выгода в шаринге контрактов, монорепе, удобстве разработки. Как только разделяем, то сразу вопрос – а зачем вообще тогда использовать node.js?

10:19пожаловаться #17

DB

неправда, просто нест дружит с class-validator из коробки, но валидационные пайпы ты можешь писать любые

Блин, а я и забыл, как год назад читал в доках про joi... спасибо за напоминание)

ILshat Khamitov in NestJS — русскоязычное сообщество

10:20пожаловаться #18

IK

класс-валидатор удобен тем что схема валидации и модель идут вместе через декораторы, а в других которые я пробовал там схема отдельным файлом, и оно разьезжается все время

10:21пожаловаться #19

DB

Нода не лучшее решение для работы с данными, писать бэки на ней имеет смысл только именно как фронт-бэки, bff. Тут сразу выгода в шаринге контрактов, монорепе, удобстве разработки. Как только разделяем, то сразу вопрос – а зачем вообще тогда использовать node.js?

Потому что ни с чем другим работать не умеем?)
Блин, а вот серьёзно, что если не нода?