Комментарии 25
Я может сейчас чего-то не понял, но где хоть одно слово про архитектуру фронта в этой статье?
Ну да
Не смотря на полезность статьи – название абсолютно не отображает ее сути:)
Добрый день. Смысл статьи в том, что необходимо разделять бизнес логику и ui логику. В целом, это первая статья из цикла статей по оптимизации и подходам на фронте. Для начала мы рассказали, как сделать жизнь легче путем автоматизации некоторых процессов (автогенерацию). В планах - рассказ, как сделать быстрый ui, затем, как все соединить в единое целое. Для ясности постараемся четче подбирать названия для статей.
Да я вообще не сварщик, я на С++ пишу :) Просто зашёл почитать про архитектуру, мало ли какой-нибудь прикольный архитектурный принцип завезли, можно будет подумать над тем, имеет ли предлагаемая архитектура право на жизнь в других языках, а тут просто обзор двух фреймворков. Сейчас название получше)
Декораторы – функционал декларативного программирования, позволяющий расширить любые методы, какие только пожелаем.
Это не функционал, а синтаксический сахар. В жс функции высшего порядка, так что декораторы встроены изначально.
Третий недостаток состоит в том, что большинство проверок на тип и пустоту требуется осуществлять вручную, так как в express.js применяется ES, а не TS. Также к минусам отнесу пляски с выставлением кукис и прочим серверным взаимодействием со стороны UI.
ES? Что мешает использовать express с TS? какие проблемы у express с cookies? И как это решает nest?
Прочим серверным взаимодействием - что конкретно не так, и как это решает nest?
Почему axios, rest, swagger, angular
Тупо кликбейт
Во-первых, из коробки express не поддерживает TS, нужны костыли и прочее. Сама структура приложений на экспрессе не предусматривает использования всех фишек TS, что ведет к снижению его эффективности.
С кукис проблема следующего характера: их на экспрессе надо постоянно парсить при каждом запросе, затем, если надо, выставлять и совершать прочие манипуляции. Упрощение работы с кукис происходит только тогда, когда мы прикручиваем сторонние плагены, но опять же это сторонние зависимости.
У nest есть базовые компоненты для работы с кукис, например, интерсептор помогает подсовывать их в автоматическом режиме при запросе к беку, или в контролерах использовать через контекст при ответах на ui.
Почему axios, rest, swagger, angular. Потому что axios позволяет нам перехватывать запросы и подсовывать мок, что упростит нам тестирование в автоматическом режиме. Rest - самый используемый паттерн взаимодействия. А это значит, что он будет большинству полезен. Но nest умеет работать почти со всем.
Swagger - самый удобный инструмент для самодокументированного кода, что позволяет протестить бек, прослойку между беком и ui , спокойно, без лишних плясок.
Angular – мы его используем в повседневной работе, но в статье также упомянуто, что можно выбрать и другие приложения, просто зайдите на сайт.
С каких пор добавление поддержки TS стало костылем? У express есть типы на TypeScript, которые зачастую используются в nestjs, nestjs все лишь набор оберток вокгур популярных решений(в том числе и express)
interceptor - это middleware которое есть в express, в express обычно так же мутируют реквест(точнее nestjs делает это так же как в express, fastify использует немного другую технику, но тут о нем речи нет)
да есть куча тулов и дока по несту имеет хорошее описание, так почему именно эти - в чем их эффективность?
Первый и самый главный — гибкость. Это означает, что при отсутствии навыков его использования вы или совершите ошибки, или случайно откроете временной портал.
дереватив гибче родителя? - ну ок
Второй недостаток — импорт. Данный функционал реализован не слишком нативно, поэтому если вы просчитались с архитектурой, то мешанины вам не избежать.
чего?
серьезно, я сам использую nest, но титул - как эффективно использовать nest.js, сводится к полуярным либам, и к сложности добавления tsconfig к экспрессу.
если использвать TS c express количество dto станет меньше?
С каких пор добавление поддержки TS стало костылем? У express есть типы на TypeScript, которые зачастую используются в nestjs, nestjs все лишь набор оберток вокгур популярных решений(в том числе и express)
Давайте по порядку, прекратить TS ко всему можно. Вопрос что может из коробки и сколько действий потребуется для того что бы начать разрабатывать с удовольствием и удобством.
interceptor - это middleware которое есть в express, в express обычно так же мутируют реквест(точнее nestjs делает это так же как в express, fastify использует немного другую технику, но тут о нем речи нет)
Его можно сгенерировать автоматически? он удобнее? Где его проще написать? Вопрос не в том что где есть, а где удобнее. Подход почти везде одинаков, исполнение везде разное. Как говориться дьявол, кроиться в деталях.
да есть куча тулов и дока по несту имеет хорошее описание, так почему именно эти - в чем их эффективность?
в статье вроде ни где не указано что они единственные и неповторимые, просто автор привел то с чем работает. Есть другие на примете, давайте делиться. С радостью прочитаю обзор и сравнение на них.
Первый и самый главный — гибкость. Это означает, что при отсутствии навыков его использования вы или совершите ошибки, или случайно откроете временной портал.
Чем гибче инструмент тем больше ответственность за архитектуру, можно натворить циклических зависимостей и прочего ненужного. Фреймворк - забирает гибкость но в замен дает стандарт использования. Так как фреймворк имеет четко очерченную зону ответственности у каждой его части.
Второй недостаток — импорт. Данный функционал реализован не слишком нативно, поэтому если вы просчитались с архитектурой, то мешанины вам не избежать
автор имел ввиду require.
серьезно, я сам использую nest, но титул - как эффективно использовать nest.js, сводится к полуярным либам, и к сложности добавления tsconfig к экспрессу.
если использвать TS c express количество dto станет меньше?
Что-то вас не понял, причем количество DTO, вопрос в том что можно автоматизировать данный процесс. С радостью выслушаем ваш опыт использования и советы по использованию.
Мне кажется, что сравнивать micro фреймворк и full-stack фреймворк — кощунство.
Это как сравнивать sinatra.rb и Ruby on Rails.
Как эффективно использовать-то? )
тут вроде рассказывается что и как. Приведенные пакеты помогут автоматизировать, алгоритм прост.
Перечень действий:
устанавливаем пакеты
с помощью @apidevtools/swagger-parser мы парсим свагер бека для того что получит JSON для обработки
потом его переводим в удобно используемый код с помощью Swagger-typescript-api
далее при помощи Swagger-ui-express мы сможем иметь свагер нашего BFF
А для автоматизации тестирования что бы подставлять моки (перехват запросов) используем Axios
выше изложенные действия экономят нам кучу времени на описания интерфейсов и прочего
Требуется выучить большой объём информации, чтобы правильно все использовать.Да нет. Его прелесть как раз в том, что стартовый проект легко заводится. Нет необходимости досконально знать каждый аспект/компонент, а можно изучать по мере необходимости.
Придётся много писать DTO, для того чтобы данные корректно обрабатывались в запросе.Странно жаловаться на это. Это как жаловаться на возможность/необходимость использовать типы в ts.
Придётся иногда делать множественные проверки по типам, например, Enum и прочие.Можно подробнее о каких проверках речь?
Да нет. Его прелесть как раз в том, что стартовый проект легко заводится. Нет необходимости досконально знать каждый аспект/компонент, а можно изучать по мере необходимости.
Большой объём инфы, по сравнению с express. А так же не надо забывать что плоха можно написать везде, а вот правильно не всегда просто. Как пример Interceptor это же по сути сервис, и его функциональность можно руками сунуть во внутрь
Странно жаловаться на это. Это как жаловаться на возможность/необходимость использовать типы в ts.
Это не жалоба, это просто примечание того что boilerplate много писать придаться в части DTO. Как пример доскональное описание полей а так же их проверок.
Можно подробнее о каких проверках речь
пример описания пары полей ниже, просто представите то у вас порядка 50 полей и на каждое надо описание как ниже
// Пример описания ответа
@ApiProperty({
description: 'Код сообщения',
type: String,
example: 'USERS_001',
})
code?: string;
@ApiProperty({
description: 'Уровень сообщения',
enum: getEnumValues(SelectedLevelTypes), /сравнение с Enum
required: false,
example: SelectedLevelTypes.INFO,
})
@IsEnum(SelectedLevelTypes)
level?: SelectedLevelTypes;
@ApiProperty({
description: 'Текст сообщения',
type: String,
example: 'Catalog service does not reply',
})
text?: string;
// описание одного поля для входного параметра
@ApiProperty({
description: 'Координаты',
type: GeolocationAddresses,
required: false,
})
@IsOptional() / параметр не обязателен в запросе
@Type(() => GeolocationAddresses) // что данное поле имеет сложное тип (тоесть
вложенность)
@ValidateNested({ each: true }) // включение проверки вложенных типов
geolocation?: GeolocationAddresses;
пример описания пары полей ниже, просто представите то у вас порядка 50 полей и на каждое надо описание как нижеТак это же для свагера. В express'е не меньше бы писать пришлось.
не совсем оно так, к свагеру относиться только код нижу
@ApiProperty({
description: 'Координаты',
type: GeolocationAddresses,
required: false,
})А все остальное это пайпы самого nestjs. О которых вы можете прочитать здесь. Так же пайпов может быть довольно-таки много если сложные проверки например, когда одно поле зависит от другого.
причем здесь пайпы - это обычные dto объекты которые будут в любом статически типизированном бэкенде. То что вам надо десерилизовать данные из запроса - в каком-нибдуь dotnetcore этого делать не надо? да надо
большие проекты на express и nestjs по структуре сильно похожи, теже +/-тулы, по сути команда nestjs обобщила хорошие практики из бэкендов на ноде и сделала удобный враппер, как next вокруг react
Обзор nest.js: как эффективно его использовать