Comments 14
_
Добрый день. Можете использовать Nest. Тут как бы на вкус и цвет. И я про это написал в статье: "Существуют уже готовые фреймворки для Node.JS, которые уже содержат в себе все необходимые пакеты и можно работать с ними, но это уже другой путь. Идея была в том, чтобы не зависить целиком от какого-то фреймворка и в случае необходимости менять одни пакеты на другие."
Именно поэтому я не рассказываю про Nest, т.к. целью этой статьи было рассказать как настраивать node.js приложение, а не NestJS framework. Framework сегодня один завтра другой, а фундаменталка реже меняется.
Если для вас Nest — только про подключенные и готовые библиотеки из коробки, то вы не поняли nest.
Интересно, как можно было прийти к такому выводу из моего комментария?
Я говорю о том, что NestJS предлагает ядро которое содержит фактически все что было описано в статье. Плюс к этому фреймворк содержит удобные точки расширения и позволяет по определенным правилам создавать и включать плагины для чего угодно.
Я за то, чтобы взять готовое решение вместо того, чтобы скручивать роутер, swagger, логгеры, адаптер к БД и т.д. с помощью синей изоленты.
Там много каши с DI, IoC, которые не каждый мидл понимает
Как раз мидл будет дольше выезжать в самописную лапшу в которой непонятно как инициалируются и соединяются друг с другом компоненты типичного nodejs+express приложения. И эта самописная лапша еще может драматически отличаться между различными приложениями.
И наоборот, при использовании DI и IoC разработчик быстрее поймет консистентную структуру приложения(й) и быстрее начнет приносить пользу добавляя новые и изменяя существующие модули
Я просто описал свой опыт работы с NodeJS. Я предпочитаю писать только о тех вещах, с которыми имел практический опыт работы. Так же призываю соблюдать этику — это я про "синия изолента"
«Создаем приложение на Node.JS, Express и Typescript с Jest, Swagger, log4js и Routing-controllers»
Автор рассказывает, как разжечь костер без спичек, а вы ему советуете использовать газовую горелку.
Как раз мидл будет дольше выезжать в самописную лапшу в которой непонятно как инициалируются и соединяются друг с другом компоненты типичного nodejs+express приложения. И эта самописная лапша еще может драматически отличаться между различными приложениями.
Плохой код является prerequisite для хорошего кода. Сразу въезжать в тему DI, тем более не задаваясь вопросами об архитектуре — не хорошая идея, только себя запутает и усложнит существующие задачи. Смысл ему усложнять, если и так хорошо? А как станет тесно, тогда и придет к DI. Но опять же, статья вовсе не об этом
Спасибо за статью! Очень пригодилась как раз для случая, когда не хочется тащить в свой проект какой-либо фреймворк в духе nestjs
Спасибо, за хорошую шпаргалку. Поделюсь по секрету - в последних версиях express уже есть встроенный body parser, поэтому устанавливать отдельно его уже не нужно.
Спасибо, он нужен был для routing-controllers. К routing-controllers есть вопросы, как и аналоги. У меня был опыт работы с ними, поэтому я о них и написал. Но это "для более удобной работы", с моей точки зрения. Т.е. лучше наверное было сказать - она не обязательна и на ваше усмотрение. Работать все будет и без нее.
Создаем приложение на Node.JS, Express и Typescript с Jest, Swagger, log4js и Routing-controllers