Т.е. каждая страница, как бы глубоко она ни была, зачем-то при ссылках использует ..?
Все страницы сразу сгенерированы и в виде файлов лежат на хосте. Все пути захардкожены .
Что насчет CORS это настройки и они легко меняются. А исполнение JS не мешает вы же подключали хоть раз jquery c помощью CDN. У вас на это ругалась система?
Нет веб -сервера, то есть не происходит исполнения. вы просто можете у себя на пк открыть .html файл и гулять по всему сайту как вам вздумается и тестировать весь функционал, без поднимания какого-то денвера или опен сервера.
В конце 90 вы делали его как?? Руками создавали дубли?? Хардкодили меняющийся текст? Jamstack автоматически генерирует страницы согласно шаблону, и без участия бэка ( точнее представления его в классическом виде? . Так же хотел бы спросить а какие вы технологии использовали в 90 - php или java?
если вы обратили внимание то сервис имеет пунктирную линию. и это использование либо для интерактива, как пример написание отзыва или оплата товара( эти действия же должны как-то попасть в бд) либо для генерации статики.
это как посмотреть, можно сделать. Но тут вопрос трудозатрат, а так же какое количество плагинов(сторонних библиотек) надо будит подключить. И опять же e-commerce бывают разные.
Апи нужно для того что бы сгенерировать статичную страницу. То есть при генерации статической страницы, у нас есть сама разметка и динамическая часть. Как пример статья, разметка одна и таже, но вот сам текст другой. Апи как раз нам позволяет вытянуть из базы (или другого истоячника ) нужную информации и сгенерировать статическую информацию.
А все остальное это пайпы самого nestjs. О которых вы можете прочитать здесь. Так же пайпов может быть довольно-таки много если сложные проверки например, когда одно поле зависит от другого.
С каких пор добавление поддержки TS стало костылем? У express есть типы на TypeScript, которые зачастую используются в nestjs, nestjs все лишь набор оберток вокгур популярных решений(в том числе и express)
Давайте по порядку, прекратить TS ко всему можно. Вопрос что может из коробки и сколько действий потребуется для того что бы начать разрабатывать с удовольствием и удобством.
interceptor - это middleware которое есть в express, в express обычно так же мутируют реквест(точнее nestjs делает это так же как в express, fastify использует немного другую технику, но тут о нем речи нет)
Его можно сгенерировать автоматически? он удобнее? Где его проще написать? Вопрос не в том что где есть, а где удобнее. Подход почти везде одинаков, исполнение везде разное. Как говориться дьявол, кроиться в деталях.
да есть куча тулов и дока по несту имеет хорошее описание, так почему именно эти - в чем их эффективность?
в статье вроде ни где не указано что они единственные и неповторимые, просто автор привел то с чем работает. Есть другие на примете, давайте делиться. С радостью прочитаю обзор и сравнение на них.
Первый и самый главный — гибкость. Это означает, что при отсутствии навыков его использования вы или совершите ошибки, или случайно откроете временной портал.
Чем гибче инструмент тем больше ответственность за архитектуру, можно натворить циклических зависимостей и прочего ненужного. Фреймворк - забирает гибкость но в замен дает стандарт использования. Так как фреймворк имеет четко очерченную зону ответственности у каждой его части.
Второй недостаток — импорт. Данный функционал реализован не слишком нативно, поэтому если вы просчитались с архитектурой, то мешанины вам не избежать
автор имел ввиду require.
серьезно, я сам использую nest, но титул - как эффективно использовать nest.js, сводится к полуярным либам, и к сложности добавления tsconfig к экспрессу.
если использвать TS c express количество dto станет меньше?
Что-то вас не понял, причем количество DTO, вопрос в том что можно автоматизировать данный процесс. С радостью выслушаем ваш опыт использования и советы по использованию.
Да нет. Его прелесть как раз в том, что стартовый проект легко заводится. Нет необходимости досконально знать каждый аспект/компонент, а можно изучать по мере необходимости.
Большой объём инфы, по сравнению с 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;
да все так и есть, я тоже видел много систем. Но как говориться нет ничего вечного. В статье я старался донести что все это утопично, и надо придерживаться адаптации к изменениям. При этом не породив новых багов которые могут быть фатальными.
Ну раз, фитиль то это все меняет. На самом деле фитиль всего лишь визуализация, анекдотов того времени. Насчет мешанина, то прошу от вас план как бы вы сделали. Или что вам не понятно, могу разъяснить.
Поддерживаю вас. Микросервисы и микрофронтенд всего лишь инструменты. как Говориться и микроскопом можно забивать гвозди только зачем? По этому я и призываю сначала думать а оно вам надо и только потом делать...
Т.е. каждая страница, как бы глубоко она ни была, зачем-то при ссылках использует ..?
Все страницы сразу сгенерированы и в виде файлов лежат на хосте. Все пути захардкожены .
Что насчет CORS это настройки и они легко меняются. А исполнение JS не мешает вы же подключали хоть раз jquery c помощью CDN. У вас на это ругалась система?
если у вас все правильно сделано то у вас не будет такого пути
Нет веб -сервера, то есть не происходит исполнения. вы просто можете у себя на пк открыть .html файл и гулять по всему сайту как вам вздумается и тестировать весь функционал, без поднимания какого-то денвера или опен сервера.
В конце 90 вы делали его как?? Руками создавали дубли?? Хардкодили меняющийся текст? Jamstack автоматически генерирует страницы согласно шаблону, и без участия бэка ( точнее представления его в классическом виде? . Так же хотел бы спросить а какие вы технологии использовали в 90 - php или java?
то есть опционально, и в очень урезанном виде по сравнению с классической схемой.
если вы обратили внимание то сервис имеет пунктирную линию. и это использование либо для интерактива, как пример написание отзыва или оплата товара( эти действия же должны как-то попасть в бд) либо для генерации статики.
это как посмотреть, можно сделать. Но тут вопрос трудозатрат, а так же какое количество плагинов(сторонних библиотек) надо будит подключить. И опять же e-commerce бывают разные.
Апи нужно для того что бы сгенерировать статичную страницу. То есть при генерации статической страницы, у нас есть сама разметка и динамическая часть. Как пример статья, разметка одна и таже, но вот сам текст другой. Апи как раз нам позволяет вытянуть из базы (или другого истоячника ) нужную информации и сгенерировать статическую информацию.
как минимум скорости написания кода, разве нет? Качество кода...
не совсем оно так, к свагеру относиться только код нижу
А все остальное это пайпы самого nestjs. О которых вы можете прочитать здесь. Так же пайпов может быть довольно-таки много если сложные проверки например, когда одно поле зависит от другого.
Давайте по порядку, прекратить TS ко всему можно. Вопрос что может из коробки и сколько действий потребуется для того что бы начать разрабатывать с удовольствием и удобством.
Его можно сгенерировать автоматически? он удобнее? Где его проще написать? Вопрос не в том что где есть, а где удобнее. Подход почти везде одинаков, исполнение везде разное. Как говориться дьявол, кроиться в деталях.
в статье вроде ни где не указано что они единственные и неповторимые, просто автор привел то с чем работает. Есть другие на примете, давайте делиться. С радостью прочитаю обзор и сравнение на них.
Чем гибче инструмент тем больше ответственность за архитектуру, можно натворить циклических зависимостей и прочего ненужного. Фреймворк - забирает гибкость но в замен дает стандарт использования. Так как фреймворк имеет четко очерченную зону ответственности у каждой его части.
автор имел ввиду require.
Что-то вас не понял, причем количество DTO, вопрос в том что можно автоматизировать данный процесс. С радостью выслушаем ваш опыт использования и советы по использованию.
ну как-то сравнивают же реакт и ангуляр? По сути тоже самое. Они оба выполняют одну и туже функцию. Вопрос удобства и порога вхождения
тут вроде рассказывается что и как. Приведенные пакеты помогут автоматизировать, алгоритм прост.
Перечень действий:
устанавливаем пакеты
с помощью @apidevtools/swagger-parser мы парсим свагер бека для того что получит JSON для обработки
потом его переводим в удобно используемый код с помощью Swagger-typescript-api
далее при помощи Swagger-ui-express мы сможем иметь свагер нашего BFF
А для автоматизации тестирования что бы подставлять моки (перехват запросов) используем Axios
выше изложенные действия экономят нам кучу времени на описания интерфейсов и прочего
Большой объём инфы, по сравнению с express. А так же не надо забывать что плоха можно написать везде, а вот правильно не всегда просто. Как пример Interceptor это же по сути сервис, и его функциональность можно руками сунуть во внутрь
Это не жалоба, это просто примечание того что boilerplate много писать придаться в части DTO. Как пример доскональное описание полей а так же их проверок.
пример описания пары полей ниже, просто представите то у вас порядка 50 полей и на каждое надо описание как ниже
Ну тут вопрос реторический как реакт и ангуляр. Но реакт разработчики говорят что ангуляр не ровня.
Опыт у всех разный. я поделился как я вижу магию. Но это не означает что других путей нету.
да все так и есть, я тоже видел много систем. Но как говориться нет ничего вечного. В статье я старался донести что все это утопично, и надо придерживаться адаптации к изменениям. При этом не породив новых багов которые могут быть фатальными.
Ну раз, фитиль то это все меняет. На самом деле фитиль всего лишь визуализация, анекдотов того времени. Насчет мешанина, то прошу от вас план как бы вы сделали. Или что вам не понятно, могу разъяснить.
если интересно подробно вот вам пару статей которые позволят понять нюансы https://habr.com/ru/company/veeam/blog/517392/ и вторая https://itsecforu.ru/2020/10/20/%F0%9F%A6%A9-%D0%B8%D0%B7%D1%83%D1%87%D0%B0%D0%B5%D0%BC-minio-%D0%B0%D0%B2%D1%82%D0%BE%D0%BD%D0%BE%D0%BC%D0%BD%D0%BE%D0%B5-%D1%85%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B5-%D0%BE%D0%B1%D1%8A/ Как минимум minio - имеет больше настроек и решает больше задач связанные с файлами статики.
Поддерживаю вас. Микросервисы и микрофронтенд всего лишь инструменты. как Говориться и микроскопом можно забивать гвозди только зачем? По этому я и призываю сначала думать а оно вам надо и только потом делать...