Галоўная / Артыкулы / NestJS протык Node.js: чаму ў большых проектах структура перажывае свабоду

Node.jsNestJSExpress.jsSoftware ArchitectureBackend Development

NestJS протык Node.js: чаму ў большых проектах структура перажывае свабоду

У этай стацыі пояснюецца, як NestJS выкарыстоўвае архітектуру шараў, впрыск залежнасцяў і стандарты на базе Node.js, каб рашыць проблемы з адтрымкай, якія не можа рашыць просты Node або Express.

1379 слоў

Параграфавыя адказы: чаму нам патрэбны NestJS

Архітэктурны развіццё сервернага JavaScript

JavaScript спачатку быў простым языкам скрыптавання для дадзення невялікай ступені інтерактыўнасці веб-сторанкам. З часам ён ператварыўся на серйозную тэхналогію, здатную працаваць у всіх бэкенд-системах. Node.js быў ключовым элементам гэтага пераходу, адколі ён дазволіў пісаць логіку сервернай часткі на тым жа языке, які развівачы вжывалі ў браузеры.

Калі аплікацыі сталаўся большымі за розмах і складнасцю, каманды пачалі сталкавацца з проблемамі ў організацыі коду, масштабаванні і дагоўнае падтрымкі. Node.js даёст неабходныы рантайм для выконання JavaScript за межамі браузера, але ён навмысна не даёт інструкцый пра тое, як следуе практыкуваць архітектуру аплікацыі. Такая відкрытасць є зручной, але у большых проектах часта прыводзіць да таго, што базы коду распрастаюцца ў неоднаковых направленнях і станавяцца важкімі для падтрымкі.

NestJS з’явіўся як рашэнне самэй гэтай проблемы. Ён стоіць на базе Node.js і включае ў сябе апрацавану архітектуру, стабільную організацыю проектаў, метод ін’екцыі залежнасцей та усталяваныя шаблоны дизайну; усё гэта спрямавана на адказванне на патрабаванні команд да стварэння масштабавальных, прыемлемых для адтульнення програмнаў у корпаратывных масштабах. NestJS не ўзаменяе Node.js — гэта спосаб керавання та регламентавання процесу стварэння та адтульнення прыкладак на базе Node.js.

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

Асновная разліка — среды выканання протыва рамак з чыста визначаным падходам: двыгун протыва автомабіля

Прыгодным спосабом разумець звязак між Node.js і NestJS ёсць параболізаванне двагухчыліндровага двыгуна з готовай аўтамабілем. І той, і другі працуюць на разных роўнях, і які-то з іх неабходныя, але яны рашаюць разныя проблемы.

  • Node.js (двыгун): среда выканання, якая дазволяе JavaScript працаваць на серверы, а не ў вікні браузера. Ён эфектыўны ў одночасным адвядзенні больш заўсёды операцый, але даўае вам абсалютна вольную плошчу без жадных встроеных правілаў ўспакою, як трэба аранжаваць ваш код.
  • NestJS (аўтамабіль): фрэймворк, пабудаваны на гэтым двыгуне. Ён задаёт структураваны, прагнозавальны план для стварэння большых застосоў. Ён не конкуруець з Node.js — ён працюе ўзаемна з яным, так што ствараны код застаецца аранжаваным і прастым у керуванні па мере його росту.

The Express.js Middle Ground and "Architectural Chaos"

Багато разработчыкаў выбіраюць Express.js як легкі інструмент для обробкі запытак у Node.js, адколькі ён являе сабою мінімалістычны і гнучкі набор засобаў для веб-запытак.

  • Яго прынада: Express практычна не накладае жадных правіл, што дазволяе чыргаваць маленькія проекты і пратотыпы адразу ж за лёгкі час.
  • Яго недакладнасць: тая ж свабода стае прычынай проблем, калі проект або команда растуе. Без спяльнай структуры код часта становіцца заплутаным, неадэкватным, важкім для тэставання і ў цялым складным для падтрымкі.

NestJS рашае гэту проблему, включаючы з самага пачатку проекта адзінучую структуру і набор правіл.

Ёнколі карацьцяцца проблемы, якія выступаюць у момант расшырэння прыложэння, NestJS значна скористаўся ідеямі з фронтэнд-фрамворку Angular і перанёс іх у сяроўыск Node.js.

Пераход з фрамворку без чыткай структуры, або з мінімалістычнага фрамворку на кшталт Express, да абсолютна структураванага фрамворку калічыцца калькольком конкрэтнымі інжынерскімі прычынамі. Нижэйшыя пункты дакладна адказваюць на пытанне, чаму команды выбіраюць NestJS замест простаго Node.js чыў Express.

Пункт 1: Аднародныя стандарты заменяюць індывідуальныя правілы

У слабка структураваных сэтапах, такіх як Express, арганізацыя кодавой базы часта залежыць ад індывідуальных правілаў — неформальных норм і прычынк, якія ведаюць толькі ўсеўядомыя автары. Новыя інжынеры, якія прыўязваюцца да такога проекту, могу пасвятіць недзелы на тое, каб проста з’ясавіць, дзе знаходзяцца элементы і як яны взаімаўязна працуюць.

NestJS узбегаець ад гэтаго, следуючы прынцыпу «звычай праўей за настройку»:

  • Заранее заданая структура: кожны проект NestJS пачынаецца з аднаго і тога ж чытра вялізвучанага пляну.
  • Мглевыя знання: паколькі всі прыкладныя рашэнні NestJS маюць аднойчынную архітэктуру, разработчык, які пераходзіць з аднаго проекту да іншага, можа майже за мгновеннае час адразу зрозумець, як усё працюе.
  • Шырэйшая адрабоўка: каманды витрачаюць значна менш часу на поясненне новым спецялістам іх унікальных налаштаванняў, а больш часу — на рэальную реалізацыю функцый.

Тэпа 2: Адразуванне з TypeScript запобегае дорогім абыекцыям

Звычайны Node.js працуе на JavaScript, ягоў мова паказвае бягучыя проблемы, зв’язаныя з дадзеннямі, толькі калі код фактычна выкананы. Нават такая дробная памылка, як опечатка, можа прывести да зупінкі рабочай системы.

NestJS рашае гэтыя проблемы, зроблівшы TypeScript часткаю першага класу самай фрэймворк:

  • Раннія выяўленне бягаў: TypeScript працуе як інтэлігентны рэвізор, пазначаючы аблыканні пад час напісання коду, а не пасля яго размешчэння.
  • Глыбока інтеграцыя: у той час як адключэнне TypeScript да проекту Express зазвычай ўскладнена і ўжо толькі часткова эфектыва, NestJS прыменяе яго адносова ў всіх частках прыемлена.
  • Прыблізна на 70% менш бягаў: выяўленне аблыканаў, зв’язаных з типамі, пад час разработкі можа усунуць да 70% бягаў пад час выканання, якія інакш дасталіся бы кінцавым корыстнікам.

Трэці пункт: Впрыск залежнасцяў і інверсія кантролю

Большыя прыемкі складаюцца з элементаў, якія завысока залежна адзін ад другога. Напрыклад, UserController зазвычай патрэбуе UserService, каб атрымаць данні прыемака. У стандартной наладзе Node.js або Express разработчыкі ручна з’ѐеднваюць гэтыя залежнасці:

const userService = new UserService();

Такой падход строго спаявае элементы між сабою, чыяму ўнаследкам прыемка стае важэйшай для развіцьбы або падтрымкі.

NestJS рашае гэту проблему за дапамой впрыскі залежнасцяў (Dependency Injection, DI) у поўнай сувязі з інверсіяй кантролю (Inversion of Control, IoC). У працоўчым режыме вбудованы контэйнер IoC з NestJS сам атрымлівае і передае неабходныя службы, замест таго каб кожны клас сам ствараў тое, што яму патрэбна:

constructor(private userService: UserService) {}

NestJS берае на сябе адпаведнальнасць за стварэнне компанентаў, кераванне ўсім іх жыцёвым циклам і ўз’яеднанне іх адно з другім, што дае архітектуру, яка застаецца модульнаю, слабкая з’ўязанай, прыемнай для тэставання і простай у адтрыманні. Ёнкс вымагае включэння бібліятак трэціх сторон, каб досягнуць падобнага вводу залежнасцяў, тады калі NestJS мае гэта функцыянал як частку самай основнай рамкі.

Тэпа 4: Модульная архітектура, створаная для безмежнага масштабавання

Тэпа 4: Модульная архітектура, створаная для безмежнага масштабавання

Калі база коду Node.js расте без якога-небудзь строгага структурнага падчынства, гэта можа прывести да заплутанага лесу взаімазалежных файлоў, дзе невялікая парадкавка ў процэсе заходжання можа неспадзевана зламаць процэс адправкі пакупкі. NestJS захоўваецца ад гэтага, выклекаючы модульную архітектуру:

  • Самастатныя блакі: Аплікацыя дзеліцца на незалежныя модулі, такія як UserModule, PaymentModule чы InventoryModule, падобна да окрэслівых калек Лего, якія складаюцца адзін з другім.
  • Ізольаваныя змены: Пакалі залежнасці між модулямі застаюцца чыстымі і чытаўнымі, перапісва чы апдэйтаванне аднаго модуля не паўтарыцца на іншыя і не зламвае іх.
  • Гатова да выкорыстоўваецца як мікросервіс: Такое чыстае раздзеленне аспектаў значна спрыяе пазнейшам разбіванню моналітнага прыемніка на меншыя мікросервісы ў меру росту вашай команды чыста продукту.

    • Пункт 5: Полны набор адзінакоў, які ўжо є

    Express даае вам толькі базовыя можлівасці маршрутызацыі, а застосаванне іншых пакетаў трэба шукаць, аналізаваць і ручна падключаць — напрыклад, для доступу да базы дадзеных чыста пераканання адрес электронной пошты. Такой падход прыносіць рызык, калі ў дзеяных з тых пакетаў можу быць проблемы з адтрымкай чыста відсутнае безпека.

    NestJS, на протыяжэнні, функцыонуе як аб’еднаны набор адзінакоў:

    • Функцыі, гатовыя да выкорыстоўвання: У яго є модулі, якія офіцыйна падтрымваюцца і якія включаюць пераканання вхідных дадзеных, захаванне безпекі, абрабатку памылак, кэшаванне чыста настройкі базы дадзеных.
    • Меншая колькасць наладкі: Не трэба витрачаць час на пошук сумісных бібліятэкаў і ўпорядкуванне іх самостайна.
    • Акцэнт на тым, што важна: Разработчыкі можаць витрачаць менш часу на налагоджэння інфраструктуры і больш часу на стварэнне реальных функцыйяў продукту.

    Спадні матэрыялы

    Усе артыкулыДаслаць брыф