Комментарии 49
Я думаю для начала стоило дать дефиницию "взрослому бекенду".
Мне кажется или они изобрели Spring на JS?
И несмотря на то, что все это обмазано архитектурным сахаром, копни чуть глубже — и опять вляпался в Express.
Думаю стоило об этом упомянуть в статье.
ps. да-да platform-agnostic — я в курсе, но скажите по-честному, часто ли для новых проектов на nest.js будут выбирать что-то отличное от дефолтных настроек?
А что плохого в Express?
Ну например (первое что в голову приходит) это мидлвары, которые пихают результат своей работы в реквест. Ну и в целом архитектура, которая подталкивает разработчика к некрасивым решениям.
Результат посредника в реквесте, это вполне вероятно самый дешевый способ передачи параметров при расшаривании сокетов между процессами.
Я на 100% не уверен, так как уже довольно долго с нодой не работал. Просто помню, что передача сокетов дочерним процессам там происходила на системном уровне. А во всех других случаях уже требовалось формировать специальное сообщение, что не очень прикольно, особенно если на мастер-процессе выполняется балансировка по ядрам.
Мидлварь просто один из слоёв обработки запроса и не больше. Недавно, кстати, приходилось как раз сохранять сокеты, чтобы по ним слать уведомления. И при кластеризации пришлось бы костылить сообщениями, чтобы синхронизировать эти сокеты между процессами. Внятных решений я не нашёл (сами коннекты шарить не получилось, только отправлять текстовые данные между процессами) и просто переписал всё на C#, где у потоков есть доступ к общей памяти.
Так ведь в этом и назначение мидлвар, разве нет? Предобработать и передать дальше. Не претендую на глубокое знание предмета, делал только небольшой REST на экспрессе, и в общем-то аллергии он у меня не вызвал.
Если использовать, условно, чтобы остановить обработку запроса (авторизация и тд) или что параллельно сделать (логирование и тд), или для какого-нибудь продвинутого DI, то ещё нормально. Но как и говорили, мидлвари подталкивают к костылям и некоторые разработчики начинают пихать в контекст через мидлвари всё, начиная от данных каких-то обработок, коннектов к базе, раббиту и прочим вещам, заканчивая каким-то непонятными функциями. И это вместо того, чтобы сделать просто нормальную архитектуру
Так проблема в middleware или в разработчиках, которые пихают всякое? Что лучше, чем middleware?
И это вместо того, чтобы сделать просто нормальную архитектуру
В целях саморазвития - посоветуйте, где можно посмотреть эту нормальную архитектуру или схематично опишите. Потому что кроме привязки к реквесту либо глобальной переменной ничего не приходит.
мидлвары, которые пихают результат своей работы в реквест
Коллизий боитесь? Можно пихать в WeakMap вместо реквеста, либо в реквест по ключу Symbol.
Тормозной
С platform-agnostic разработчики конечно капельку лукавят.
Но я знаю несколько примеров рабочих проектов (и все мои петы), которые используют fastify адаптер
Вспоминается один из комментариев под подобной статьёй на одном небезызвестном сайте:
Поздравляю! Вы превратили nodejs в более дерьмовую версию java.
Так это смотря что вы хотите от производительности.
На одной из работ, нода в виде достаточно тонкой прослойки между клиентом и базой данных, вполне себя нормально показывала. Но правда там и на мощностях особо не экономили, и брали дедики с достаточно большим запасом. Не помню какие конкретно процы там стояли, помню что 12 ядер, примерно на 300-400 тыс. онлайна нода загружала где-то процентов на 15-20%. В общем наш отдел не задумывался об оптимизациях серверной части. При этом соседний отдел аналитики свои сервисы уже на go делал.
Интересно в двух словах про то, из чего состоял проект. Экспресс? И какой коннектор к какой бд использовался? Сам недавно переписал бек своего CRUD движка с php на node и подобный опыт мне ужасно интересен, любые крупицы : ) Пока я так заморочен оптимизацией, что обработку запросов написал на встроенном нодовском http.
У нас был голый драйвер mongodb. Со стороны админки еще прикрутил meteor.js, но с этой стороны никакой нагрузки практически не было. Оперировать с бд необходимо было только с парой-тройкой коллекций по сути. Все остальные данные выгружались в кэш, и по требованию со стороны админки, могли инвалидироваться, но это требовалось не часто.
На счет express плохо помню, скорей всего там тоже использовался нодовский http напрямую, плюс какая-то минимальная обертка для валидации токенов авторизации и роутинга. Выдача токенов происходила через сторонний сервис, но для валидации, полученные значения еще кэшировались в коллекцию бд. Впрочем, как я понимаю, у самого экспресса, накладные расходы должны быть минимальными, основная часть там наверняка приходится на роутинг.
В остальном там у нас какого-то круда не было. Это был скорее сервис для установки и хранения некого состояния изолированного пользователя, с парой десятков методов обращения через http. Основная логика была клиентской. В какой-то момент там добавилась логика, для которой необходимо были всякие агрегации, проверки связей, хождение в несколько коллекций и прочее, но на эту часть в любом случае нагрузка была минимальной, плюс это взаимодействие происходило через веб-сокеты, поэтому на сколько я помню, часть информации кэшировалась в редисе и сбрасывалась, при сбросе сессии.
Ну и кстати сейчас еще кое-что вспомнил, по поводу оптимизаций. Там наибольшее количество информации требовалось передавать при инициализации каких-то частей приложения, но эта информации была практически всегда статичной. Поэтому клиент ее тоже кэшировал, и синхронизация происходила по высчитанным хэшам для каких-то логических блоков информации. Правда в нашем случае эта оптимизация скорее была необходима для ускорения инициализации, а не для уменьшения нагрузки на сервер.
Но все равно тянет на TypeScript - тот же Котлин только еще и со свободой JS.
Котлин тоже без спеки и с палёными декораторами и структурной типизацией? Не знал. Кстати компилится всё в js и по итогу работает тоже как js, так что кроме внешнего сходства с котлином(шарпом и чем ещё там) ничего нет. А то до производительности, так с ней у ноды никогда проблем не было, если юзать для задач на которые она ориентированна. Зачастую заменяет невывозящий jvm, можете погуглить.
С типизацией то, что что это не котлиновская типизация (а именно с ним было сравнение). А с декораторами то, что это не стандарт, а декораторы js уже на подходе...
Мне кажется оригинальный комментарий все же был про реализацию на Си глючной версии половины Лиспа, который прозвучал еще лет 30 назад)
А в целом, инструменты это просто инструменты, какими из них воспользоваться, каждый выбирает сам.
Очередная сладкая песня, что если добавить тесты, типизацию и DI, то накодить MVP сможет даже жук или жаба.
Или найдет готовую от экспресса и вкрячит ее под капот несту. И опять вернулись к тому, от чего пытались уйти.
А что не так с мидлварью?
Вообще-то это как раз новый виток эволюции и Коа выгодно отличается от Экспресс (от тех же авторов) как раз развитием в сторону мидлвар и ещё большим упрощением работы с нею, так что и ребенок справится.
Или вы считаете главнвм признаком "взрослости" фреймворка - заоблачный порог вхождения?
Неужели без этого всего нельзя написать бэкенд?)
Джависты не уймуться никак, то ТС-ом вселенной голову морочат, то Спрингом в шкуре нода.
Nest - последний фреймворк в списке взрослого бэкэнда, который вам нужен!
Первый в этом списке : Коа, за ним Экспресс ну и тыщи их собратьев ...
Но только не nest !!!
Недостатки:
1) Так как фреймворк «относительно» новый то до сих пор есть детские болезни, которые требуют лечения собственными костылями. Но работа над новыми версиями фреймворка всё ещё продолжается и последняя аннонсированная версия уберёт необходимость в части костылей.
2) Автор проекта не особо пытается помочь разобраться в возникающих вопросах (думаю, потому что по этому фреймворку он ведёт платные курсы, хе-хе). Однако, за всё время работы мне ни разу не пришлось лезть в сурсы фреймворка чтобы разобраться в чём-то, что, несомненно, плюс.
Меня в Nest раздражают две вещи:
1) Как только мы в контроллере получаем объект ответа, @Res Nest отдаёт нам весь контроль над ответом, и вместо return приходится писать res.json
2) В Guard, если мы хотим HTTP код, отличный от 403 нужно выбрасывать исключение.
Я рад, что ДомКлик обратил внимание на данный фреймворк. :)
P.S: Внутри нашей экосистемы (я так же являюсь сотрудником экосистемы Сбер, но в другой компании) мы одни из самых первых внедрили его у себя (уже почти 2 года работаем) на части проектов.
Можно было бы упомянуть Loopback 4 и сравнить с Nest.js
Статья очень своевременная ;)
Взрослый back-end на node.js возможен?