Questo articolo è basato sul mio capstone per la City University di Seattle. Il titolo della mia ricerca è “Software Documentation and Architectural Analysis of Full Stack Development”. L’obiettivo della mia ricerca era di ridurre la curva di apprendimento nella comprensione dei progetti open source e dello sviluppo completo dello stack, e ho scelto lo Stack MEDIO.
Ho creato i seguenti diagrammi, usando Lucidchart, per una più facile comprensione. Questi diagrammi UML erano basati sul modello 4 + 1 architectural view:
- Restaurant Analogy
- Process View using Sequence Diagram
- Scenario using Sequence Diagram
- Physical View using Deployment Diagram
- Development View using Package Diagram
- Logical View using Class Diagram
The research was more focused on Deployment and Request and Response Flow.
Lo Stack MEDIO è una soluzione open-source JavaScript full-stack. È composto da MongoDB, Express, Angular e Node.js.
L’idea alla base è quella di risolvere i problemi comuni con la connessione di tali framework, costruire un framework robusto per supportare le esigenze di sviluppo quotidiane e aiutare gli sviluppatori a utilizzare pratiche migliori mentre lavorano con i componenti JavaScript più diffusi.
Back-end con Nodo.js
Nodo.js è costruito per la gestione di I / O asincrono mentre JavaScript ha un ciclo di eventi integrato per il lato client. Questo rende Nodo.js veloce rispetto ad altri ambienti. Tuttavia, l’approccio event-driven / callback rende Nodo.js difficile da imparare ed eseguire il debug.
Nodo.js include moduli come Mongoose, che è una modellazione di oggetti MongoDB, e Express web application framework. Attraverso i moduli Node, è possibile ottenere l’astrazione, che riduce la complessità complessiva dello stack MEDIO.
Back-end con Express Framework
Express è un framework applicativo minimalista e non aperto per Node.js. È un livello in cima al Nodo.js che è ricco di funzionalità per lo sviluppo web e mobile senza nascondere alcun nodo.funzionalità js.
Front-end con Angular
Angular è una piattaforma di sviluppo web costruita in TypeScript che fornisce agli sviluppatori strumenti robusti per la creazione del lato client delle applicazioni web.
Consente lo sviluppo di applicazioni Web a pagina singola in cui il contenuto cambia dinamicamente in base al comportamento e alle preferenze dell’utente. È dotato di dependency injection per garantire che ogni volta che un componente viene modificato, altri componenti ad esso correlati verranno modificati automaticamente.
Database con MongoDB
MongoDB è un database NoSQL che memorizza i dati in BJSON (Binary JavaScript Object Notation).
MongoDB è diventato il database standard de facto per Node.applicazioni js per soddisfare il paradigma” JavaScript everywhere ” utilizzando JSON (JavaScript Object Notation) per trasmettere dati su diversi livelli (front-end, back-end e database).
Ora che abbiamo ottenuto quelle basi di mezzo, diamo un’occhiata a questi diagrammi.
Ristorante Analogia
Come ho voluto affrontare la curva di apprendimento ripida, ho scelto un ristorante analogia per consentire all’utente di comprendere e mantenere il processo per la richiesta e la risposta in un’applicazione full stack.
Il cliente (utente finale) richiede il proprio ordine tramite il cameriere (controller), e il cameriere consegna la richiesta alla persona alla finestra dell’ordine (service factory).
Questi tre componenti costituiscono il server front-end. La fabbrica di servizio sarà quella di comunicare con il cuoco (controller) nel back-end. Il cuoco poi afferrare gli ingredienti necessari (dati) in frigo (server di database).
Il frigorifero sarà in grado di fornire il materiale necessario (dati) al cuoco nel back-end. Il cuoco può ora elaborare i dati e inviare di nuovo alla fabbrica di servizio del front-end.
Il controllore (cameriere) consegnerà il pasto preparato al cliente (utente). Il cliente sarà ora in grado di consumare il pasto (dati).
Process View using Sequence Diagram
Chi lo usa o cosa mostra:
- Integratori
- Prestazioni
- Scalabilità
Nella vista processo, mostro il server front-end e il server back-end separatamente in un primo momento e poi li collego insieme al server di database.
Nel primo esempio, un’applicazione angolare è stata distribuita con JSON hard-coded in un file service.ts (situato nella fabbrica del servizio).
L’applicazione Angular può comunicare con API di terze parti per ottenere dati e visualizzarli all’utente.
Nel nostro back-end, il Nodo.l’esempio di applicazione js inizia con un JSON hard-coded che può essere elaborato e utilizzato come risposta.
Questo back-end può essere collegato ad API di terze parti o ad un server di database per ottenere il JSON, elaborarlo e rispedirlo al richiedente.
Con il server front-end, back-end server, database e server di processi spiegato, mi mostra la combinazione di questi tre server di seguito:
Quando una richiesta HTTP, il front-end sarà attivato Angolare ritirare la richiesta. La richiesta verrà passata internamente in Angular con il percorso che invia una richiesta per la vista da Visualizzare / Modello.
Vista / Modello richiederà il Controller. Il controller creerà quindi una richiesta HTTP a un endpoint RESTful (Representational state transfer) sul lato Server, che è Express/Node.js. La richiesta verrà quindi passata internamente con Express / Node.js dal suo percorso al Controller / Modello.
Il Controller/Modello farà una richiesta tramite Mongoose ODM di interagire con il server di database che ha MongoDB. MongoDB elaborerà la richiesta e risponderà alla richiamata a Express / Node.js.
Espresso / Nodo.js invia una risposta JSON al controller angolare. Il controller angolare risponderebbe quindi con una vista.
Scenario Visualizzare utilizzando il Diagramma di Sequenza
Chi lo usa o quello che mostra:
- Descrivere le interazioni tra gli oggetti e tra i processi
Lo scenario sopra descritto comporta un utente che accede a un negozio di libri di applicazione. Quando l’utente inserisce l’URL, JavaScript verrà eseguito e colpirà il router del server front-end, che è AppRoutingModule. AppRoutingModule chiamerà BooksComponent, che caricherà fetchBooks come iniezione di dipendenza.
fetchBooks creerà quindi una richiesta HTTP al server back-end che dispone di un router, un controller e un modello per elaborare la richiesta e interrogare il server del database.
Il server di database elabora la query e, con il server back-end in attesa, acquisirà i dati e li invierà al server front-end come risposta JSON.
Il front-end avrà ora i dati e la vista del modello da mostrare all’utente.
Vista fisica usando il diagramma di distribuzione
Chi lo usa e cosa mostra:
- System engineer
- Topologia
- Comunicazioni
Il diagramma di distribuzione mostra 3 server: front-end, back-end e database. Nel front-end, abbiamo bisogno del browser come applicazioni angolari sono applicazioni web basate su browser.
Il server back-end ospita il nostro Nodo.js con Express in cima al nodo.js. In Express, abbiamo l’applicazione e la mangusta sopra di esso. Express gestirà la comunicazione sia sul front-end che sul database. Il server di database include solo MongoDB. Utilizza JSON per comunicare tra i server.
Nella nostra prima build dello Stack MEDIO, distribuiremo localmente usando la nostra macchina locale (localhost) per distribuire il server front-end, il server back-end e il server di database.
Useremo le seguenti porte predefinite: Angular-port 4200, Node.js / Espresso-porta 3000, e MongoDB-porta 27017.
Lo schema seguente mostra l’applicazione web full stack in notazione UML.
Passando alla produzione effettiva, la cosa da migrare al cloud è il nostro database. Per MongoDB, ho scelto MongoDB Atlas come soluzione cloud.
L’ultimo passaggio per la distribuzione di produzione consiste nel caricare il nostro codice front-end su Amazon S3 e nel caricare il back-end in un’istanza EC2 con AWS. Tutti comunicherebbero tra loro con endpoint HTTP / HTTPS.
Ecco un altro diagramma per mostrare la nostra distribuzione di produzione senza usare la notazione UML.
Sviluppo di Visualizzazione utilizzando il Package Diagram
Chi lo usa e cosa si vede:
- Programmatori
- Gestione Software
Il pacchetto vista Angolare applicazione mostra che ogni Componente Angolare è importato in AppModule. AppModule e AppRoutingModule dipendono da BooksComponent. Il BooksComponent dipende da BookDetailComponentDialog e ApiService.
La vista del pacchetto del Nodo.l’applicazione js mostra che tutte le operazioni CRUD (controller) come fetch all books, fetch a book, update a book ed delete a book vengono importate dall’app. Inoltre, tutta la logica delle operazioni CRUD risiede nel libro dei modelli.
Visualizzazione logica usando il diagramma di classe
Chi lo usa e cosa mostra:
- Utente finale
- Funzionalità
L’applicazione book store mostrava solo una singola classe chiamata Book. I membri della classe sono: titolo, isbn, autore, immagine e prezzo. I metodi sono: addBook, fetchBooks, fetchBook, updateBook e deleteBook.
La struttura del libro modello in formato JSON.
Ecco alcuni video per i diagrammi:
Documentation available on my GitHub:
Find me on LinkedIn. =)