Как стать автором
Обновить

Комментарии 49

Я думаю для начала стоило дать дефиницию "взрослому бекенду".

Мне кажется или они изобрели Spring на JS?

Nest.js кмк больше вдохновлен Angular. Впрочем это разработчики и не скрывают.

Самая большая и серьезная проблема у Nest.js это то, что по умолчанию под капотом у него все тот же «любимый» всеми Express.js
И несмотря на то, что все это обмазано архитектурным сахаром, копни чуть глубже — и опять вляпался в Express.
Думаю стоило об этом упомянуть в статье.
ps. да-да platform-agnostic — я в курсе, но скажите по-честному, часто ли для новых проектов на nest.js будут выбирать что-то отличное от дефолтных настроек?

А что плохого в Express?

Ну например (первое что в голову приходит) это мидлвары, которые пихают результат своей работы в реквест. Ну и в целом архитектура, которая подталкивает разработчика к некрасивым решениям.

Результат посредника в реквесте, это вполне вероятно самый дешевый способ передачи параметров при расшаривании сокетов между процессами.

Я на 100% не уверен, так как уже довольно долго с нодой не работал. Просто помню, что передача сокетов дочерним процессам там происходила на системном уровне. А во всех других случаях уже требовалось формировать специальное сообщение, что не очень прикольно, особенно если на мастер-процессе выполняется балансировка по ядрам.

Мидлварь просто один из слоёв обработки запроса и не больше. Недавно, кстати, приходилось как раз сохранять сокеты, чтобы по ним слать уведомления. И при кластеризации пришлось бы костылить сообщениями, чтобы синхронизировать эти сокеты между процессами. Внятных решений я не нашёл (сами коннекты шарить не получилось, только отправлять текстовые данные между процессами) и просто переписал всё на C#, где у потоков есть доступ к общей памяти.

Так ведь в этом и назначение мидлвар, разве нет? Предобработать и передать дальше. Не претендую на глубокое знание предмета, делал только небольшой REST на экспрессе, и в общем-то аллергии он у меня не вызвал.

Если использовать, условно, чтобы остановить обработку запроса (авторизация и тд) или что параллельно сделать (логирование и тд), или для какого-нибудь продвинутого DI, то ещё нормально. Но как и говорили, мидлвари подталкивают к костылям и некоторые разработчики начинают пихать в контекст через мидлвари всё, начиная от данных каких-то обработок, коннектов к базе, раббиту и прочим вещам, заканчивая каким-то непонятными функциями. И это вместо того, чтобы сделать просто нормальную архитектуру

Nest как бы и предлагает кучу решений помимо мидлваров.

Так проблема в middleware или в разработчиках, которые пихают всякое? Что лучше, чем middleware?

И это вместо того, чтобы сделать просто нормальную архитектуру

В целях саморазвития - посоветуйте, где можно посмотреть эту нормальную архитектуру или схематично опишите. Потому что кроме привязки к реквесту либо глобальной переменной ничего не приходит.

мидлвары, которые пихают результат своей работы в реквест

Коллизий боитесь? Можно пихать в WeakMap вместо реквеста, либо в реквест по ключу Symbol.

Тормозной

С platform-agnostic разработчики конечно капельку лукавят.

Но я знаю несколько примеров рабочих проектов (и все мои петы), которые используют fastify адаптер

Вспоминается один из комментариев под подобной статьёй на одном небезызвестном сайте:

Поздравляю! Вы превратили nodejs в более дерьмовую версию java.

Это звучит как комплимент для NestJs )

А вообще интересно как с производительностью у этой штуки. Я сейчас для себя пришел к Kotlin + Jooby/Kooby + Dagger2 - кайфовая связка, очень простая, гибкая, стартует моментально и судя по TechEmpower еще и очень быстрая. Но все равно тянет на TypeScript - тот же Котлин только еще и со свободой JS. А тут еще и NestJs подоспел, который не вызывает отторжения )

Так это смотря что вы хотите от производительности.

На одной из работ, нода в виде достаточно тонкой прослойки между клиентом и базой данных, вполне себя нормально показывала. Но правда там и на мощностях особо не экономили, и брали дедики с достаточно большим запасом. Не помню какие конкретно процы там стояли, помню что 12 ядер, примерно на 300-400 тыс. онлайна нода загружала где-то процентов на 15-20%. В общем наш отдел не задумывался об оптимизациях серверной части. При этом соседний отдел аналитики свои сервисы уже на go делал.

Интересно в двух словах про то, из чего состоял проект. Экспресс? И какой коннектор к какой бд использовался? Сам недавно переписал бек своего CRUD движка с php на node и подобный опыт мне ужасно интересен, любые крупицы : ) Пока я так заморочен оптимизацией, что обработку запросов написал на встроенном нодовском http.

У нас был голый драйвер mongodb. Со стороны админки еще прикрутил meteor.js, но с этой стороны никакой нагрузки практически не было. Оперировать с бд необходимо было только с парой-тройкой коллекций по сути. Все остальные данные выгружались в кэш, и по требованию со стороны админки, могли инвалидироваться, но это требовалось не часто.

На счет express плохо помню, скорей всего там тоже использовался нодовский http напрямую, плюс какая-то минимальная обертка для валидации токенов авторизации и роутинга. Выдача токенов происходила через сторонний сервис, но для валидации, полученные значения еще кэшировались в коллекцию бд. Впрочем, как я понимаю, у самого экспресса, накладные расходы должны быть минимальными, основная часть там наверняка приходится на роутинг.

В остальном там у нас какого-то круда не было. Это был скорее сервис для установки и хранения некого состояния изолированного пользователя, с парой десятков методов обращения через http. Основная логика была клиентской. В какой-то момент там добавилась логика, для которой необходимо были всякие агрегации, проверки связей, хождение в несколько коллекций и прочее, но на эту часть в любом случае нагрузка была минимальной, плюс это взаимодействие происходило через веб-сокеты, поэтому на сколько я помню, часть информации кэшировалась в редисе и сбрасывалась, при сбросе сессии.

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

Но все равно тянет на TypeScript - тот же Котлин только еще и со свободой JS.

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

Что не так с декораторами и структурной типизацией?

С типизацией то, что что это не котлиновская типизация (а именно с ним было сравнение). А с декораторами то, что это не стандарт, а декораторы js уже на подходе...

А что в котлин за супер типизация?

Номинальная, на сколько я помню. Но думаю вам с такими вопросами это не о чём не скажет.

А все обязаны знать котлин?

Ок, хорошо, котлин и тайпскрипт одно и то же, ваша взяла.

Декораторы JS "уже на подходе" с 2015, а по факту - уже сколько лет на stage 2 без прогресса. Ну как без прогресса - уже минимум 4я на моей памяти несовместимая с предыдущей итерация предложения.

Это правда конечно, но всё же рано или поздно они будут. Сейчас очень удобно заниматься разработкой на декораторах в тс, но как это скажется потом не известно.

Мне кажется оригинальный комментарий все же был про реализацию на Си глючной версии половины Лиспа, который прозвучал еще лет 30 назад)

А в целом, инструменты это просто инструменты, какими из них воспользоваться, каждый выбирает сам.

Очередная сладкая песня, что если добавить тесты, типизацию и DI, то накодить MVP сможет даже жук или жаба.

Но качественные инструменты помогут и штатному разработчику, по ощущениям не сказал бы что Nest для нубов, скорее наоборот.
Хоть Nest и предоставляет всю свободу чистого Express или Fastify, но помимо этого он предлагает готовые решения по структурированию кода. Если на том же express неопытный жук пойдет простым путем и добавит очередную миддлварю, то на Nest он уже дважды подумает и возможно найдет лучшее решение.

Или найдет готовую от экспресса и вкрячит ее под капот несту. И опять вернулись к тому, от чего пытались уйти.

А что не так с мидлварью?

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

Или вы считаете главнвм признаком "взрослости" фреймворка - заоблачный порог вхождения?

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

Неужели без этого всего нельзя написать бэкенд?)

Джависты не уймуться никак, то ТС-ом вселенной голову морочат, то Спрингом в шкуре нода.

Nest - последний фреймворк в списке взрослого бэкэнда, который вам нужен!

Первый в этом списке : Коа, за ним Экспресс ну и тыщи их собратьев ...

Но только не nest !!!

Пишу микросервисы на Nest.js уже года три — полёт нормальный. Фреймворк подойдёт тем, кому нравится opinionated фреймворки с навязанной структурой и воркфлоу.
Недостатки:
1) Так как фреймворк «относительно» новый то до сих пор есть детские болезни, которые требуют лечения собственными костылями. Но работа над новыми версиями фреймворка всё ещё продолжается и последняя аннонсированная версия уберёт необходимость в части костылей.
2) Автор проекта не особо пытается помочь разобраться в возникающих вопросах (думаю, потому что по этому фреймворку он ведёт платные курсы, хе-хе). Однако, за всё время работы мне ни разу не пришлось лезть в сурсы фреймворка чтобы разобраться в чём-то, что, несомненно, плюс.

Меня в Nest раздражают две вещи:

1) Как только мы в контроллере получаем объект ответа, @Res Nest отдаёт нам весь контроль над ответом, и вместо return приходится писать res.json

2) В Guard, если мы хотим HTTP код, отличный от 403 нужно выбрасывать исключение.

Соглашусь

Посмотрите в сторону tsed, если не сталкивались

Я рад, что ДомКлик обратил внимание на данный фреймворк. :)

P.S: Внутри нашей экосистемы (я так же являюсь сотрудником экосистемы Сбер, но в другой компании) мы одни из самых первых внедрили его у себя (уже почти 2 года работаем) на части проектов.

Можно было бы упомянуть Loopback 4 и сравнить с Nest.js

Интересно было бы услышать мнение человека который детально работал с обоими фреймворками. Лупбэк я трогал очень поверхностно. Но кажется лупбэк не нужен т.к. они опоздали

Так же интересует сравнение с TSEd

Статья очень своевременная ;)

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.