1 Cos’è Node.js
Quando diversi anni fa, veniva eseguito dai browser codice JavaScript, poteva essere solo lanciato dal computer sul quale il browser era installato. Per questo si è sempre nomenclatore il linguaggio javaScript come client side. Node js è un linguaggio multipiattaforma che permette l’esecuzione di javascript anche lato server. Questo è reso possibile grazie al suo motore ( engine ) V8,
Quando diversi anni fa fu realizzato il browser Chrome, Google realizzò un esecutore di codice javaScript dentro il suo browser molto veloce e potente, il V8 per l’appunto. Google rese il motore V8 open source. L’idea fu quella di modificare il sorgente del V8 per permettere l’esecuzione di JavaScript anche sui server, tanto che oggi JavaScript può essere utilizzato anche per accedere e modificare il filesystem o per interagire col database, nonché servire richieste HTTP ( server REST ).
Grazie a node.js diventa possibile eseguire codice javaScript sul server.
Rispetto ad altri linguaggi, node.js ha la caratteristica di essere a modello Input / Output non bloccante ad eventi.
Nel modello I/O bloccante tipico degli altri linguaggi le risorse (thread) rimangono impegnate fintanto che le risposte da parte del server non vengono soddisfatte.
Nel modello non bloccante ad eventi, il singolo thread non attende la risposta dal server, prima di processare nuove richieste, ma durante la fase di elaborazione richiesta, genera una call back e va a processare altre richieste. Quando una risposta da parte del server arriva viene generato un evento. Questo permette maggiore scalabilità e minori richieste hardware laddove viene fatto un grande uso della rete, mentre diventa sconsigliato e poco efficiente quando le applicazioni necessitano di grande utilizzo di CPU, tipo elaborazioni grafiche .
Ricapitolando: node.js utilizza un modello di I/O non bloccante ad eventi, ovvero quando arrivano le richieste in input sul server, node.js elabora con un singolo thread molte di queste richieste. Nel momento in cui una richiesta è bloccante, tipo una chiamata ad un database, crea una call back. Nel momento in cui viene restituita la richiesta, viene scaturito un evento ed inserito in una coda. Questa coda viene processata dal thread, il quale risolve poi gli eventi e restituisce l’output al client.
Un framework molto utile per node.js è express. Dato che javaScript è un linguaggio molto libero che non pone molti vincoli architetturali, cosicché in progetti complessi si potrebbe creare diversa confusione nel codice con difficile gestione e manutenzione. Per creare una sorta di struttura su un’eventuale applicativo possiamo ricorrere all’ausilio di express JS. Un concetto interessante da capire con express js è il concetto di middleware, che si possono considerare come dei blocchi che si vanno ad inserire nel nostro applicativo node.js che aiutano ad inserire delle funzionalità aggiuntive. Ogni modulo middleware invia 4 parametri:
- ERROR per la gestione degli errori
- REQ per la gestione della richiesta
- RES per la gestione della risposta
- NEXT che è la call back alla funzione successiva che si deve richiamare
Express include builtin già una quindicina di middleware che si possono aggiungere più altri che è possibile installare separatamente tramite npm. Ogni modulo fornisce una caratteristica come per esempio la compression che si occupa della compressione di file in zip o il cookie parse che consente di lavorare con i cookie.
REST
REST è uno stile architetturale molto diffuso, specialmente con l’avvento delle apps mobile. È l’acronimo di REpresentational State Transfer. Il concetto fondamentale in REST è la risorsa che è esposta al client sia per modifiche che per consultazione. La risorsa è da intendersi nel concetto di identificativo globale URI di cui nella maggior parte dei casi, il riferimento più utilizzato è la URL raggiunta tramite il protocollo HTTP. Infatti ogni app mobile effettua delle chiamate HTTP solitamente tramite URL a delle risorse messe a disposizione dal server rispondono in forma di API REST. Tutta la business logic è spostata sul core delle nostre REST API che saranno la parte back-end. La parte front-end sarà spostata sulle app dei nostri dispositivi, creando le SPA, single page application che si preoccuperanno di effettuare solamente delle chiamate al server e visualizzare i risultati all’utente, in altre parole sono applicazioni stupide, in quanto non hanno logica. Questo stile di logica ha permesso a REST di diventare molto popolare negli ultimi anni. Inoltre molto spesso le API REST possono interagire oltre che con web app o SPA anche con altre API esterne (classico esempio sono le API di Google Maps ).
Formati per la comunicazione dei dati
Come abbiamo visto possono esserci diverse comunicazioni tra Beck-end e front-end, i principali tipi di dato che vengono scambiati sono :
- HTML
Un server REST necessita perlopiù di dati grezzi e lo scambio di dati HTML, racchiusi tra i tag diventa difficile l’estrazione dei dati - Text
Con i file di testo, dobbiamo pensare ad una struttura personalizzata, in cui incastonare questo testo e progettare un Customer parser per decodificare questi dati - XML
Con questo formato è possibile estrarre i dati facilmente tramite un XML parser, unica pecca è che questo parser è molto oneroso in termini di risorse, raramente è la scelta corretta di trasmissione - JSON
Questo è lo standard che si è adottato de facto, è la scelta corretta, in quanto i meta-dati sono auto espletati e rimane il miglior formato attualmente utilizzato per le web application e REST
I principi di REST
- uniforme
Uno degli aspetti che caratterizza un applicativo REST è realizzare un’interfaccia uniforme con una logica che rimanga perlopiù invariata - client/server
Un dispositivo effettua delle richieste e una macchina server risponde. I server non devono occuparsi di quello che è l’interfaccia grafica dell’utente dando molta scalabilità agli applicativi e gli applicativi sia client che server possono essere upgradati separatamente, senza dipendere l’uno dall’altro - stateless
Di default il server non ha mai traccia del client che effettua le richieste, questo rappresenta un pericolo per le applicazioni, a meno di non ricorrere ad escamotage come JWT o il OAUTH - cache
Quando ben strutturato, un server può far uso del sistema di cache per soddisfare in modo più rapido le richieste. Bisogna ottimizzare al meglio i dati contenuti nella cache rispetto a quelli reali del db - livelli
Un client effettua una richiesta al server REST che se non le ha al suo interno, le va a richiedere a sua volata altri server, recuperando le informazioni che servono a soddisfare la richiesta del client. Una pratica comune è quella dei microservizi che si occuperanno di rispondere a determinate operazioni
Metodi HTTP
Sono i metodi che permettono di effettuare operazioni sulle URL
- GET
Una chiamata effettuata sul browser per il recupero di un indirizzo, per esempio una chiamata GET su bloccoappunti.it/javascript-es6 risponderà con tutte le lezioni di JavaScript. Il GET può essere visto come una chiamata di lettura - POST
Una chiamata di scrittura, vado a creare un nuovo articolo per il corso Javascript, andrò a comunicare al server, il quale scriverà i nuovi dati nel db - PUT
Molto simile al POST, ma l’operazione è di modifica - DELETE
Operazione per la cancellazione - PATCH
Poco utilizzate sono simili alle PUT, ma permettono di inviare i dati in modo spezzettato - OPTIONS
Anche queste vengono utilizzate meno e servono per la verifica se su un URL esistono alcune delle 5 precedenti operazioni. Questa operazione viene automaticamente eseguita ogni volta dai browser. Possono venir utili nell’affrontare il problema del CORS.
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b
a
b