Начало работы с Nest.js и размышления о корпоративном подходе

Я стажер Node.js.После поступления в Dasouche мне посчастливилось увидеть фреймворк Akyuu.js. Но этот фреймворк — это способ использования Express + Callback, который мне не очень нравится. По моей рекомендации и по инициативе сообщества руководитель группы решил попробовать TS + Async/Await. Так что я также отправился изучать внутренние фреймворки TS, и после того, как меня порекомендовали другие, я нашел фреймворк с Nest.js, который почти такой же, как у меня.

Введение в структуру

Поскольку это не учебник для меня, поэтому я не буду вдаваться в подробности, вы можете ознакомиться с ним.Nest.jsОфициальный сайт. С моей точки зрения восприятия я кратко расскажу о следующих характеристиках:

• Децентрализованная маршрутизация. Все маршруты привязаны к контроллеру через декораторы. Простой, понятный и низкая стоимость обучения.
• Поддержка TypeScript/Rx.js. Умное завершение, анализ кода, статическая типизация и многое другое. Если вы используете его только лично, он может показаться очень полным. Но использование его на предприятии — очень большое преимущество.
• Внедрение зависимости. Учился у Angular, но с некоторыми упрощениями, но вполне адекватно. Например, deps упрощаются.
• идея модуля. Серверные платформы сообщества Node на самом деле ориентированы на режим промежуточного программного обеспечения Express. Nest.js же взял идею модулей из Angular. Различные службы, контроллеры и компоненты образуют разные модули. Модули могут зависеть друг от друга или существовать независимо, что значительно снижает сложность тестирования и логики.
• Легко расширяется. В предыдущих фреймворках вы могли только писать бизнес-логику, и вам было сложно заниматься другими делами. Поэтому традиционная внутренняя структура должна была представить набор подключаемых модулей для повышения расширяемости среды. Но в Nest.js есть плагины, встроенные прямо в фреймворк. Традиционный плагин здесь можно рассматривать как модуль, а различные функции добавляются путем загрузки разных модулей.
• Экспресс краеугольный камень. Некоторые люди скажут, разве Коа сейчас не лучшая модель? Луковая модель может решать более сложные задачи. Да, я ничего не имею против этого утверждения. Но я хочу сказать, что Express — это самый простой и универсальный способ, потому что он неплох для Generator/Promise, вам нужна только другая среда выполнения Node.js, поддерживающая Callback. (Другими словами, не должно быть среды Node.js, которая не поддерживает Callback, хахаха) В любом случае охват Express все же намного шире, чем у Koa.
• Все дороги ведут в Рим. Потом кто-то спросил, что мне делать, если я хочу реализовать луковую модель? Я бы сказал, что всегда будет способ. В Nest.js через Interceptor можно хорошо реализовать onion-модель. Другими словами, вы можете использовать Interceptor для записи времени, затрачиваемого на запрос.
• Синхронный код. Синхронный код здесь — это не просто async/await. Во многих фреймворках, поддерживающих async/await, если вы хотите вернуть значение, если оно Express, вам все равно нужно вызватьresp.send(await getValue()), а коа тоже надо звонитьctx.body = await getValue(). Но в Nest.js просто нужноreturn await getValue()Вот и все. Напишите код бизнес-логики для достижения настоящей синхронизации.
• логическое наслоение. На самом деле многие функции могут быть реализованы через промежуточное ПО. Однако к разным типам функций предъявляются разные требования, и если они будут реализованы только через промежуточное ПО, это неизбежно приведет к некоторому дублированию кода. Таким образом, Nest.js вводит логические уровни, такие как Pipe/Interceptor/Guard/ExceptionFilter. Подобные вещи обрабатываются в разных слоях, например, Pipe обрабатывает преобразование входных данных. Interceptor реализует луковую модель. Guard используется для задач перехвата, таких как проверка разрешений. ExceptionFilter используется для обработки данных об ошибках. Преимущество такого расслоения в том, что оно может сделать код более понятным, и мастеру нужно думать о том, что должен делать этот слой, вместо того, чтобы думать об этом на уровне промежуточного ПО.
• Проверка. У него своя калибровка, и он прекрасно сочетается с ТС, очень удобен в использовании, смотритеруководство
• Преобразование входных параметров. На самом деле это очень удобный аспект. Иногда вам нужно преобразовать входной параметр в класс, в это время вы можете преобразовать его через Валидацию. Если вы не хотите использовать автоматическое преобразование, вы можете использовать традиционный метод ручного преобразования.
• Функция тестирования работает отлично. Тестирование невероятно просто благодаря внедрению зависимостей. Более того, официальный также предоставляет ряд инструментов тестирования, которые также могут очень хорошо решить проблему модульного тестирования.

Проблемы с Nest.js Enterprise

• Каталог не ограничен. На предприятии отсутствие ограничений на каталоги может привести к еще большему загромождению кода. Это снижает ремонтопригодность кода.
• Функция управления конфигурацией отсутствует. В разработке фреймворка конфигурация часто является очень важной функцией. Например, настроить подключение к базе данных и настроить порт прослушивания.
• Нет управления процессами. Хотя при условии@nestjs/cli, но это дает только возможность создать проект.
• Некоторые документы не объясняют подробно, что повысит порог въезда.

Но в целом предыдущие пункты также являются гарантией гибкости Nest.js. Но нам действительно нужно разумное ограничение в процессе развития, чтобы обеспечить единство развития.

Попытка предприятия Nest.js

Итак, здесь мы пытаемся использовать некоторые способы ограничения вышеперечисленных проблем.

Структура каталогов

Мы указываем следующие правила для проектов:

• Все написано на TypeScript и все находится вsrcПод содержанием
• Входной файлmain.tsЕсли нет особых обстоятельств, не перемещайте этот файл
• настроить вsrc/configв папке
• Все сервисы/контроллеры/логика/компоненты и т. д. монтируются наMainModuleВниз.
• вmoduleВ папках хранятся пользовательские модули, или они надеются быть независимыми модулями, но не были полностью независимыми. Структура каталогов аналогична структуре каталогов проекта.
• bootПапка выполняется при запуске кода проекта, в Nest.js эта часть не указана. Я планирую добавить эту функцию сюда, но я не разобрался с конкретной формой реализации, так что это предстоит определить.
• interface/enumПодождите, пока данные будут экспортированы соответствующим сервисом. Не указано иное. Напримерcar.service.tsПомимо экспортаCarServiceПомимо классов, вы также можете экспортироватьCarTypeперечисление
• destПапка представляет собой скомпилированный файл, вы можете войти в нее напрямуюnode dest/main.jsбегать.
• соглашение об именовании
  • Все файлы, кроме main.ts и файлов классов, должны добавлять суффикс типа, напримерuser.model.ts car.controller.ts google.logic.ts. Но, например, простоCarкласс, то он может быть назван непосредственно какcar.ts
  • не разрешено проходитьexport defaultэкспорт данных. С одной стороны, это обеспечение единообразия именования при импорте, а с другой стороны, interface/enum и другой контент можно экспортировать в любой момент.
  • Все тестовые файлы имеют суффикс.spec.tsили.test.tsконец.

|-- dest
    |--- ...
|-- src
    |-- config
    |-- controller
    |-- model
    |-- service
    |-- logic
    |-- component
    |-- boot
    |-- module
        |-- module-name
            |-- config
            |-- index.ts
            |-- module-name.module.ts
    |-- main.ts
    |-- main.module.ts

Управление конфигурацией

Моя текущая первоначальная идея состоит в том, чтобы предоставитьConfigModuleразоблачитьConfigServiceдля обеспечения доступа к конфигурации и просмотра.

В некоторых случаях может потребоваться многоуровневая конфигурация, конфигурация на уровне модуля и конфигурация на уровне приложения. ТакConfigServiceЭти правила могут быть автоматически объединены при получении конфигурации.

Управление процессом

Прошло уже 18 лет, ты действительно заслуживаешь себя без Докера? Очевидно извините. Итак, управление процессами мы оставляем на долю Докера. Включая запуск, остановку, перезапуск, журнал и т. д., все они передаются Docker.

Таким образом, команду запуска можно упростить доnode dest/main.jsВот и все.

Тогда вы можете подумать, что если среда Docker назначит вам два u, не будет ли это тратить впустую один u. Теоретически да, тогда можно и самому через pm2 управлять, хахаха, не смотря ни на что.

Iron.js

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

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

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

Вот что я узнал за неделю использования Nest.js. Это все, о чем я могу думать на данный момент, и я проанализирую больше позже.

Написав, я легла спать и пообещала женский голос, ля-ля-ля~