Pull to refresh

Comments 14

Хм. А почему бы сразу не взять фреймворк NestJS? Не нужно соединять вместе express + typescript + routing-controllers + swagger. Там все это есть уже (или почти) из коробки в более согласованном и удобном виде.

Добрый день. Можете использовать Nest. Тут как бы на вкус и цвет. И я про это написал в статье: "Существуют уже готовые фреймворки для Node.JS, которые уже содержат в себе все необходимые пакеты и можно работать с ними, но это уже другой путь. Идея была в том, чтобы не зависить целиком от какого-то фреймворка и в случае необходимости менять одни пакеты на другие."

Если для вас Nest — только про подключенные и готовые библиотеки из коробки, то вы не поняли nest. Там много каши с DI, IoC, которые не каждый мидл понимает

Именно поэтому я не рассказываю про Nest, т.к. целью этой статьи было рассказать как настраивать node.js приложение, а не NestJS framework. Framework сегодня один завтра другой, а фундаменталка реже меняется.

Да, я об этом и говорю в ответ комментатору выше

Если для вас Nest — только про подключенные и готовые библиотеки из коробки, то вы не поняли nest.


Интересно, как можно было прийти к такому выводу из моего комментария?

Я говорю о том, что NestJS предлагает ядро которое содержит фактически все что было описано в статье. Плюс к этому фреймворк содержит удобные точки расширения и позволяет по определенным правилам создавать и включать плагины для чего угодно.

Я за то, чтобы взять готовое решение вместо того, чтобы скручивать роутер, swagger, логгеры, адаптер к БД и т.д. с помощью синей изоленты.
Там много каши с DI, IoC, которые не каждый мидл понимает


Как раз мидл будет дольше выезжать в самописную лапшу в которой непонятно как инициалируются и соединяются друг с другом компоненты типичного nodejs+express приложения. И эта самописная лапша еще может драматически отличаться между различными приложениями.

И наоборот, при использовании DI и IoC разработчик быстрее поймет консистентную структуру приложения(й) и быстрее начнет приносить пользу добавляя новые и изменяя существующие модули

Я просто описал свой опыт работы с NodeJS. Я предпочитаю писать только о тех вещах, с которыми имел практический опыт работы. Так же призываю соблюдать этику — это я про "синия изолента"

DI — это отдельная тема для разговора, которая явно не вписывается в тему
«Создаем приложение на Node.JS, Express и Typescript с Jest, Swagger, log4js и Routing-controllers»

Автор рассказывает, как разжечь костер без спичек, а вы ему советуете использовать газовую горелку.
Как раз мидл будет дольше выезжать в самописную лапшу в которой непонятно как инициалируются и соединяются друг с другом компоненты типичного nodejs+express приложения. И эта самописная лапша еще может драматически отличаться между различными приложениями.


Плохой код является prerequisite для хорошего кода. Сразу въезжать в тему DI, тем более не задаваясь вопросами об архитектуре — не хорошая идея, только себя запутает и усложнит существующие задачи. Смысл ему усложнять, если и так хорошо? А как станет тесно, тогда и придет к DI. Но опять же, статья вовсе не об этом

Спасибо за статью! Очень пригодилась как раз для случая, когда не хочется тащить в свой проект какой-либо фреймворк в духе nestjs

Спасибо, за хорошую шпаргалку. Поделюсь по секрету - в последних версиях express уже есть встроенный body parser, поэтому устанавливать отдельно его уже не нужно.

Спасибо, он нужен был для routing-controllers. К routing-controllers есть вопросы, как и аналоги. У меня был опыт работы с ними, поэтому я о них и написал. Но это "для более удобной работы", с моей точки зрения. Т.е. лучше наверное было сказать - она не обязательна и на ваше усмотрение. Работать все будет и без нее.

Sign up to leave a comment.

Articles