Implementazione di un'architettura pulita con Nest.JS

Questo articolo è per gli appassionati che si sforzano di scrivere codice pulito, scalabile e, soprattutto, refactorable. Darà un'idea di come Nest.JS può aiutarci a scrivere codice pulito e quale architettura sottostante utilizza.

L'implementazione di un'architettura pulita con Nest.JS richiederà prima di tutto di comprendere cos'è questo framework e come funziona.

Nest o Nest.JS è un framework per la creazione di applicazioni Node.js efficienti e scalabili (lato server) create con TypeScript. Utilizza Express o Fastify e consente un livello di astrazione per consentire agli sviluppatori di utilizzare un'ampia quantità di moduli (di terze parti) all'interno del loro codice.

Scaviamo più a fondo in cosa consiste questa architettura pulita. 

Bene, potreste aver usato o almeno sentito parlare dell'architettura MVC. MVC sta per Model, View, Controller. L'idea alla base di questo è quella di separare la struttura del nostro progetto in 3 diverse sezioni.

1. Modello: conterrà il file Oggetto che mappa con Relazione/Documenti nel DB.

2. Titolare: È il gestore della richiesta ed è responsabile dell'implementazione della logica di business e di tutta la manipolazione dei dati.

3. Visualizza: Questa parte conterrà file che riguardano la visualizzazione dei dati, file HTML o alcuni file del motore di creazione di modelli.

Per creare un modello, abbiamo bisogno di una sorta di strumento/modulo/libreria ORM/ODM con cui costruirlo. Ad esempio, se utilizzi direttamente il modulo, diciamo "sequelizza", quindi utilizza lo stesso per implementare l'accesso nel tuo controller e rendere la tua logica aziendale principale dipendente da "sequelizzazione". Ora, in fondo, diciamo dopo 10 anni, c'è uno strumento migliore sul mercato che vuoi usare, ma non appena sostituisci sequelize con esso, dovrai cambiare molte righe di codice per impedirgli di rottura. Inoltre, dovrai testare nuovamente tutte le funzionalità per verificare se è stato distribuito correttamente o meno, il che potrebbe anche far perdere tempo e risorse preziose. Per superare questa sfida, possiamo utilizzare l'ultimo principio di SOLID che è il principio di inversione delle dipendenze e una tecnica chiamata iniezione di dipendenza per evitare un tale pasticcio.

Ancora confuso? Lascia che ti spieghi in dettaglio.

Quindi, ciò che il Principio di inversione delle dipendenze dice in parole semplici è che crei la tua logica aziendale principale e quindi costruisci la dipendenza attorno ad essa. In altre parole, libera la tua logica principale e le regole di business da qualsiasi tipo di dipendenza e modifica gli strati esterni in modo tale che dipendano dalla tua logica principale invece che dalla tua logica dipendente da questa. Ecco cos'è l'architettura pulita. Elimina la dipendenza dalla tua logica aziendale principale e costruisce il sistema attorno ad essa in modo tale che sembrino dipendere da essa piuttosto che da essa.

Proviamo a capirlo con il diagramma sottostante.

Fonte: Cono di architettura pulita 

Puoi vedere che abbiamo diviso la nostra architettura in 4 livelli:

1. Entità: Al suo interno, le entità sono i modelli (regole aziendali) che definiscono le regole aziendali e raccontano di cosa tratta l'applicazione. Questo livello difficilmente cambierà nel tempo ed è solitamente astratto e non accessibile direttamente. Ad esempio, ogni applicazione ha un 'utente'. Tutti i campi che l'utente deve memorizzare, i loro tipi e le relazioni con altre entità comprenderanno un'entità.

2. Casi d'uso: Ci dice come possiamo implementare le regole aziendali. Riprendiamo l'esempio dell'utente. Ora sappiamo su quali dati operare, il caso d'uso ci dice come operare su questi dati, ad esempio l'utente avrà una password che deve essere crittografata, l'utente deve essere creato e la password può essere modificata in qualsiasi dato momento, ecc.

3. Controller/gateway: Questi sono canali che ci aiutano a implementare i casi d'uso utilizzando strumenti e librerie esterni utilizzando l'iniezione di dipendenze.

4. Strumenti esterni: Tutti gli strumenti e le librerie che utilizziamo per costruire la nostra logica rientreranno in questo livello, ad es. ORM, Emailer, Crittografia, ecc.

Gli strumenti che utilizziamo dipenderanno da come li canalizziamo verso i casi d'uso e, a loro volta, i casi d'uso dipenderanno dalle entità che sono il fulcro della nostra attività. In questo modo abbiamo invertito la dipendenza dall'esterno verso l'interno. Questo è ciò che implica il principio di inversione delle dipendenze di SOLID.

Ok, ormai hai l'essenza di Nest.JS e hai capito come funziona l'architettura pulita. Ora sorge la domanda, come sono collegati questi due?  

Proviamo a capire quali sono i 3 elementi costitutivi di Nest.JS e cosa fa ciascuno di essi.

1. moduli: Nest.JS è strutturato in modo tale da poter trattare ogni caratteristica come un modulo. Ad esempio, tutto ciò che è collegato all'Utente come modelli, controller, DTO, interfacce, ecc., può essere separato come un modulo. Un modulo ha un controller e un gruppo di provider che sono funzionalità iniettabili come servizi, orm, emailer, ecc.

2. Controller: I controller in Nest.JS sono interfacce tra la rete e la tua logica. Vengono utilizzati per gestire le richieste e restituire risposte al lato client dell'applicazione (ad esempio, chiamate all'API).

3. Fornitori (servizi): I provider sono servizi/funzionalità iniettabili che possiamo iniettare nei controller e in altri provider per fornire flessibilità e funzionalità extra. Astraggono ogni forma di complessità e logica.

Riassumere,

• Abbiamo controller che fungono da interfacce (3° livello di architettura pulita)
• Abbiamo provider che possono essere inseriti per fornire funzionalità (4° livello di architettura pulita: DB, dispositivi, ecc.)
• Possiamo anche creare servizi e repository per definire il nostro caso d'uso (2° livello)
• Possiamo definire le nostre entità utilizzando fornitori di database (1° livello)

Conclusione:

Nest.JS è un potente framework Node.JS e il più noto dattiloscritto disponibile oggi. Ora che hai le nozioni di base su questo framework, ti ​​starai chiedendo se possiamo usarlo per costruire una struttura di progetto con un'architettura pulita. Ebbene, la risposta è -Sì! Assolutamente. Come? Spiegherò nella prossima serie di questo articolo. 

Fino ad allora, restate sintonizzati!

Circa l'autore:

Junaid Bhat sta attualmente lavorando come Tech Lead in Mantra Labs. È un appassionato di tecnologia che si sforza di diventare un ingegnere migliore ogni giorno seguendo gli standard del settore e allineandosi a un approccio più strutturato alla risoluzione dei problemi. 

Leggi il nostro ultimo blog: Golang-Beego Framework e sue applicazioni

Conoscenza che vale la pena consegnare nella tua casella di posta