Den här artikeln är till för entusiaster som strävar efter att skriva ren, skalbar och ännu viktigare kod. Det kommer att ge en uppfattning om hur Nest.JS kan hjälpa oss att skriva ren kod och vilken underliggande arkitektur den använder.

Att implementera en ren arkitektur med Nest.JS kräver att vi först förstår vad det här ramverket är och hur det fungerar.

Nest eller Nest.JS är ett ramverk för att bygga effektiva, skalbara Node.js-applikationer (serversidan) byggda med TypeScript. Den använder Express eller Fastify och tillåter en abstraktionsnivå för att göra det möjligt för utvecklare att använda en stor mängd moduler (tredje part) i sin kod.

Låt oss gräva djupare i vad den här rena arkitekturen handlar om. 

Tja, ni kanske alla har använt eller åtminstone hört talas om MVC-arkitektur. MVC står för Model, View, Controller. Tanken bakom detta är att dela upp vår projektstruktur i 3 olika sektioner.

1. Modell: Den kommer att innehålla objektfilen som mappas med Relation/Documents i DB.

2. Styrenhet: Det är begäranhanteraren och ansvarar för implementeringen av affärslogik och all datamanipulation.

3. Visa: Den här delen kommer att innehålla filer som handlar om att visa data, antingen HTML-filer eller några mallmotorfiler.

För att skapa en modell behöver vi någon form av ORM/ODM-verktyg/modul/bibliotek att bygga den med. Till exempel, om du direkt använder modulen, låt oss säga "uppföljning" och sedan använda densamma för att implementera inloggning i din kontroller och göra din kärnverksamhetslogik beroende av "uppföljningen". Nu, låt oss säga efter 10 år, finns det ett bättre verktyg på marknaden som du vill använda, men så fort du ersätter uppföljaren med det, måste du ändra många rader kod för att förhindra att det brytning. Dessutom måste du testa alla funktioner en gång till för att kontrollera om de har distribuerats framgångsrikt eller inte, vilket kan slösa bort värdefull tid och resurser också. För att övervinna denna utmaning kan vi använda den sista principen i SOLID som är Dependency Inversion Principle, och en teknik som kallas beroendeinjektion för att undvika en sådan röra.

Fortfarande förvirrad? Låt mig förklara i detalj.

Så vad Dependency Inversion Principle säger i enkla ord är att du skapar din kärnverksamhetslogik och bygger sedan beroende kring den. Med andra ord, frigör din kärnlogik och affärsregler från alla slags beroenden och modifiera de yttre lagren på ett sådant sätt att de är beroende av din kärnlogik istället för din logik beroende av detta. Det är vad ren arkitektur är. Det tar bort beroendet från din kärnverksamhetslogik och bygger systemet runt det på ett sådant sätt att de verkar vara beroende av det snarare än att det är beroende av dem.

Låt oss försöka förstå detta med diagrammet nedan.

Källa: Ren arkitekturkon 

Du kan se att vi har delat in vår arkitektur i 4 lager:

1. Enheter: Entiteter är i sin kärna modellerna (Enterprise-regler) som definierar dina företagsregler och berättar vad applikationen handlar om. Detta lager kommer knappast att förändras över tiden och är vanligtvis abstrakt och inte direkt tillgängligt. Till exempel har varje applikation en "användare". Vilka alla fält användaren ska lagra, deras typer och relationer med andra enheter kommer att utgöra en Entitet.

2. Användningsfall: Den berättar för oss hur vi kan implementera företagsreglerna. Låt oss ta exemplet med användaren igen. Nu vet vi vilken data som ska hanteras, användningsfallet talar om för oss hur vi ska hantera dessa data, som att användaren kommer att ha ett lösenord som måste krypteras, användaren måste skapas och lösenordet kan ändras när som helst given tidpunkt osv.

3. Styrenheter/Gateways: Det här är kanaler som hjälper oss att implementera användningsfallen med hjälp av externa verktyg och bibliotek med hjälp av beroendeinjektion.

4. Externa verktyg: Alla verktyg och bibliotek vi använder för att bygga vår logik kommer att hamna under detta lager, t.ex. ORM, Emailer, Kryptering, etc.

De verktyg vi använder kommer att bero på hur vi kanaliserar dem för användningsfall och i sin tur kommer användningsfall att bero på de enheter som är kärnan i vår verksamhet. På så sätt har vi inverterat beroendet från utåt till inåt. Det är vad SOLIDs Dependency Inversion Principal antyder.

Okej, vid det här laget har du förstått kärnan i Nest.JS och förstått hur ren arkitektur fungerar. Nu uppstår frågan, hur dessa två är relaterade?  

Låt oss försöka förstå vad de tre byggstenarna i Nest.JS är och vad var och en av dem gör.

1. moduler: Nest.JS är uppbyggt på ett sådant sätt att vi kan behandla varje funktion som en modul. Till exempel kan allt som är kopplat till användaren såsom modeller, styrenheter, DTO:er, gränssnitt etc. separeras som en modul. En modul har en kontroller och ett gäng leverantörer som är injicerbara funktioner som tjänster, orm, e-postmeddelanden, etc.

2. controllers: Styrenheter i Nest.JS är gränssnitt mellan nätverket och din logik. De används för att hantera förfrågningar och returnera svar till klientsidan av applikationen (till exempel anrop till API).

3. Leverantörer (tjänster): Leverantörer är injicerbara tjänster/funktioner som vi kan injicera i controllers och andra leverantörer för att tillhandahålla flexibilitet och extra funktionalitet. De abstraherar alla former av komplexitet och logik.

För att sammanfatta,

• Vi har kontroller som fungerar som gränssnitt (tredje lagret av ren arkitektur)
• Vi har leverantörer som kan injiceras för att tillhandahålla funktionalitet (fjärde lagret av ren arkitektur: DB, enheter, etc.)
• Vi kan också skapa tjänster och arkiv för att definiera vårt användningsfall (2nd Layer)
• Vi kan definiera våra enheter med hjälp av DB-leverantörer (1st Layer)

Slutsats:

Nest.JS är ett kraftfullt Node.JS-ramverk och det mest välkända typskriptet som finns tillgängligt idag. Nu när du har fått ner det här ramverket måste du undra om vi kan använda det för att bygga en projektstruktur med en ren arkitektur. Tja, svaret är -Ja! Absolut. Hur? Jag ska förklara i nästa serie av denna artikel. 

Tills dess, håll utkik!

Om författaren:

Junaid Bhat arbetar för närvarande som Tech Lead i Mantra Labs. Han är en teknikentusiast som strävar efter att bli en bättre ingenjör varje dag genom att följa industristandarder och anpassa sig till ett mer strukturerat förhållningssätt till problemlösning. 

Läs vår senaste blogg: Golang-Beego Framework och dess tillämpningar

Det är värt att leverera kunskap i din inkorg