L’architettura client-server popolare divide la comunicazione in due parti: una che si occupa di tutti i pesanti compiti e fornisce servizi, nota come server, e l’altra che fruisce di tali servizi, nota come client.
Nella comunicazione client-server generale, il client invia semplicemente una richiesta chiedendo risorse o servizi al server, e il server risponde a tale richiesta.
Per la comunicazione client-server, client e server devono disporre di librerie che possono comprendere il protocollo in cui stanno comunicando. Un protocollo è una lingua o un insieme di regole di comunicazione Internet. Sono meccanismi di trasporto che seguono alcune linee guida per il trasporto dei dati su Internet.
Il secondo aspetto più importante della comunicazione del client è il formato del messaggio su cui sia il client che il server possono concordare. Questo formato del messaggio si basa su alcuni schemi, e non seguendo questi schemi, la comunicazione non avverrebbe. I formati dei messaggi possono essere simili a XML, che rispetta uno schema, o a un file JSON, che deve contenere specifici valori chiave-valore.
Un altro aspetto importante di questo tipo di comunicazione da capire è che si basa su un meccanismo di richiesta e risposta, il che significa che il server comunica solo quando il client avvia la comunicazione. Con REST e GraphQL, questo è per lo più unidirezionale. Questa è una problematica di base che verrà risolta dalla tecnologia come gRPC.
Perché è nata REST?
Negli anni ’90, un popolare protocollo client-server chiamato SOAP utilizzava un formato di messaggio XML con uno schema hardcoded. Lo schema per il formato del messaggio era molto rigido. La mancanza di libertà è ciò che ha causato l’abbandono di SOAP e l’emergere di REST.
REST è venuto alla ribalta a causa della crescente popolarità di JavaScript, che ha portato alla crescita nella popolarità del formato di file JSON. Era semplice da capire e conveniente. Aveva solo alcune coppie di chiavi e valori nel suo formato di messaggio.
In parole semplici, Rest è una linea guida per trasferire messaggi JSON attraverso Internet con HTTP come suo protocollo (meccanismo di trasporto). Con Rest, non c’è bisogno di preoccuparsi di creare uno schema.
Che cos’è REST?
Abbiamo parlato dell’emergere di REST. Ora approfondiamo la sua tecnologia di base. Quindi lascia che ti dica che REST sta per Representational State Transfer. Rest è uno stile architetturale software standardizzato, un API ampiamente utilizzato nell’industria.
Motivi della popolarità e dell’uso diffuso di REST
- REST è semplice e standardizzato per l’architettura di comunicazione. Utilizzando R, non dovresti preoccuparti di formattare il tuo messaggio o i tuoi dati. Non è necessario preoccuparsi del formato del messaggio ogni volta, poiché è tutto standardizzato e utilizzato nell’industria.
- REST è scalabile. Se il tuo servizio diventa più grande e ha bisogno di più funzionalità, puoi facilmente ristrutturare il tuo server senza preoccuparti delle prestazioni di REST del server e puoi creare nuove funzioni in isolamento a meno che non stiano rovinando i tuoi dati.
- REST è senza stato. Ciò significa che ogni richiesta conterrà alcuni dati che devono essere compresi dal server. L’architettura del server consente al server di ricordare le informazioni di questa richiesta, ma nell’architettura REST, lo stato della sessione è memorizzato sul lato client, rendendo il server più efficiente e dandogli un carico di lavoro minimo per una funzionalità più fine.
- Infine, ma non meno importante, Rest è un’architettura ad alte prestazioni e supporta la memorizzazione nella cache.
Quando Usare REST
Immagina di creare un sito web per un ristorante. Hai tutti i menu online e gli elementi di cibo sono suddivisi in tre categorie:
- Antipasti
- Pietanze principali
- Bevande
Ora, diciamo che vuoi vedere tutte le bevande online. Nell’architettura Rest, puoi facilmente e coerentemente suddividere tutti i tuoi risorse su endpoint API. Ovviamente, puoi utilizzare più autenticazioni su di essi per renderli sicuri.
In questo tipo di caso, inviamo una richiesta GET al server a un endpoint dove possiamo ottenere i dati delle risorse bevande.
Allo stesso modo, possiamo eseguire tutte le operazioni CRUD (Create, Read, Update, Delete) nell’API Rest, il che la rende adatta per grandi progetti che non richiedono trasferimenti di dati super-veloci e non devono essere in tempo reale.
Rest funziona al meglio per progetti in cui il trasferimento efficiente dei dati è un fattore importante. La memorizzazione nella cache è un’altra caratteristica di REST che è utile per applicazioni standard come app di prenotazione di cibo, app di prenotazione alberghiera, siti web di blog, siti web di forum, ecc.
Limitazioni e Problemi con REST
REST è fantastico, ma presenta diversi svantaggi che possono risultare cruciali in alcuni casi. Parliamone.
- La necessità di comunicazione bidirezionale.
E se il server dovesse inviare dati al client? Il server desidera iniziare la comunicazione. Nell’architettura REST, questo non è possibile. Certo, si possono usare alcuni stratagemmi, ma non sono pratici. - Immagina di creare un sito web con punteggi live. Come gestiresti il server per inviare una richiesta al client per aggiornare i dati dei punteggi? Potremmo far sì che i clienti inviino richieste ogni 10 secondi, ma non è una buona pratica. Ciò sovraccaricherebbe il server, il che potrebbe causare problemi di velocità.
- L’architettura REST è puramente richiesta e risposta e non supporta la trasmissione dei dati (elaborazione di eventi continui).
- La proprietà REST di essere senza stato può essere considerata una benedizione e una maledizione, poiché non si può decidere lo stato dei dati nell’architettura REST.
Perché è nato gRPC?
Per affrontare il primo problema di REST, che è la necessità di comunicazione bidirezionale, è stato inventato WebSocket, che permette al server di avviare la comunicazione, ma il problema è che non ha un formato. Invio solo byte e non ha restrizioni.
I WebSocket non avevano problemi propri, ma il vero problema è che qualsiasi tipo di comunicazione richiede un protocollo, e ogni protocollo richiede una libreria client che possa comunicare utilizzando quel protocollo.
Se stai creando un’applicazione Python basata sull’architettura Rest, avrai bisogno di un client HTTP in grado di comunicare con il server. In molti casi, le librerie client sono sviluppate da terze parti, principalmente da sviluppatori indipendenti. L’uso di librerie di terze parti può esporre la tua sicurezza e l’intera applicazione dipenderà da una terza parte per la comunicazione.
Nel caso di un’applicazione web, il browser funge da libreria client, ma per progetti non web, avrai bisogno di una libreria client di terze parti. Se stai pensando di crearne una propria, tieni presente che non è così semplice e ti imporrai di mantenere un’altra applicazione.
Quindi, per affrontare alcuni problemi con Rest e per affrontare problemi con le librerie client, Google ha inventato gRPC nel 2015.
Per gRPC, una libreria client è mantenuta da Google per quasi tutti i linguaggi di programmazione popolari. Utilizza il protocollo HTTP 2 nel back-end e il protocol buffer (protobuf) come formato messaggi.
Non devi preoccuparti di alcuna libreria client, poiché Google la gestisce per te e per quasi ogni linguaggio di programmazione. Una singola e centralizzata libreria client è una delle principali forze di gRPC.
Un altro vantaggio di gRPC è il formato messaggi utilizzato. Il protocol buffer è indipendente dal linguaggio, quindi puoi creare client in Python e server in Go e comunque essere in grado di comunicare senza fare alcun problema.
gRPC è essenzialmente una libreria client e un protocollo che può essere utilizzato su qualsiasi dispositivo.
Che cos’è gRPC?
gRPC utilizza il protocollo protobuf per la comunicazione. Serializza i file proto in formato binario e li invia al server, dove vengono deserializzati nel formato originale. È così che funziona con il protobuf.
gRPC offre diverse modalità di comunicazione. Puoi considerarle come caratteristiche di gRPC.
Caratteristiche di gRPC
- Richiesta singola:Si tratta di un semplice tipo di comunicazione richiesta-risposta in cui il client invia una richiesta proto e, ricevutala, il server attende un po’ di tempo per eseguire un processo e poi restituisce una risposta.
- Streaming server:Effettuando una singola richiesta, un flusso di dati viene restituito come risposta dal server. Ad esempio, quando si fa clic su un video, un’enorme quantità di dati relativi al video arriva dal lato server.
- Streaming client:È il contrario dello streaming server. Qui il client invia molti dati in una volta sola al server. Ad esempio, ciò accade quando si condivide un file di grandi dimensioni su internet o si carica un’immagine o un video su internet. Il client invia costantemente dati al lato server.
- Streaming bidirezionale:In questo tipo di comunicazione, il client e il server inviano più messaggi. Il chat è un ottimo esempio di ciò.
Queste sono quattro caratteristiche popolari di gRPC che lo rendono così potente.
Quando utilizzare gRPC
Per quanto riguarda le caratteristiche di gRPC, abbiamo visto alcuni casi d’uso per gRPC. Immaginiamo di voler creare un’applicazione di chat. Non si utilizzerà l’API Rest poiché non sarà in grado di consentire una rapida trasmissione di comunicazione bidirezionale. Per questo, utilizzeremo lo stream gRPC, che offrirà alcuni ulteriori vantaggi oltre alla velocità.
In primo luogo, il suo comportamento indipendente dal linguaggio non importa in quale linguaggio di programmazione il server o altri client sono scritti. La comunicazione può ancora essere stabilita finché il formato del messaggio è accettato.
Quindi, con questa caratteristica, la versione Android dell’app di chat può comunicare con la versione iOS e viceversa.
Problemi con gRPC
Ci sono problemi con tutto, compreso gRPC.
- Supporto limitato dei browser: gRPC utilizza HTTP 2, quindi è difficile chiamare direttamente il servizio gRPC dal browser, il che a volte richiede la configurazione di un proxy.
- Forma non leggibile: Come sappiamo tutti, gRPC utilizza un formato binario che non è leggibile dagli esseri umani. È uno svantaggio in alcuni casi.
- Mancanza di maturità: gRPC è stato sviluppato nel 2015, quindi è ancora un po’ immaturo rispetto a REST, e molte bug e problemi devono essere risolti.
- Problemi di apprendimento: Rest e GraphQL utilizzano JSON, che è più facile da imparare. La maggior parte delle persone cercherà di attenersi a loro poiché protobuf è ancora un argomento nuovo e complesso, quindi sarà difficile trovare esperti di gRPC.
REST vs. gRPC:
Ora discuteremo della differenza tecnica tra REST e gRPC.
Formato del messaggio:
Il formato del messaggio utilizzato da REST è per lo più JSON (a volte formato XML), che è più leggibile ed è più facile da gestire. Non dovrai preoccuparti dello schema in Rest. D’altra parte, gRPC utilizza un protocol buffer per serializzare i dati. La forma compressa è più leggera e veloce da trasportare. È in formato binario, quindi serializza e deserializza i dati per trasmetterli.
HTTP 1.1 vs. HTTP 2:
L’API Rest utilizza generalmente HTTP 1.1 come protocollo, mentre gRPC utilizza HTTP 2 come protocollo sottostante. L’API Rest può ancora utilizzare HTTP 2 ma è ancora limitata a causa del meccanismo di richiesta-risposta. gRPC utilizza HTTP 2 e sfrutta il supporto di HTTP 2 sia per la comunicazione client-risposta che per la comunicazione bidirezionale. Questo è un altro aspetto che rende le prestazioni di gRPC migliori di quelle di REST. Può gestire richieste unidirezionali come HTTP 1.1 e richieste bidirezionali simultaneamente come HTTP 2.
Latenza:
La bassa latenza e la velocità elevata in comunicazione di gRPC lo rendono utile per connettersi a sistemi che consistono di architettura di microservizi leggeri, che aumenta l’efficienza della trasmissione dei messaggi. Nella maggior parte dei casi di rete, la latenza di REST richiede 25 ms, mentre la latenza di gRPC è molto inferiore a quella di REST.
Limite del payload:
Rest ha un limite massimo di payload di 45MB quando si inviano messaggi in uscita, mentre gRPC non ha alcun limite, il che significa che il tuo messaggio in uscita può essere pesante quanto vuoi.
Sicurezza:
Per quanto riguarda la sicurezza, Rest sarà in ritardo poiché utilizza HTTP 1.1 e formato JSON, che è facile da decrittare e accedere. D’altra parte, gRPC utilizza HTTP 2, che è molto più sicuro, e utilizza protobuf, che è in formato binario e difficile da decrittare.
Velocità:
Anche in questo caso, gRPC vince, poiché offre 10 volte più velocità di Rest, e questo per lo stesso motivo, utilizzando HTTP 2 come protocollo e protobuf come formato messaggio.
Funzione di generazione di codice
Rest non fornisce funzionalità di generazione di codice integrate, il che significa che lo sviluppatore ha bisogno di app di terze parti per produrre codice API, mentre gRPC ha funzionalità di generazione di codice native a causa del suo compilatore protobuf, che è compatibile con numerose lingue di programmazione. Questa è un’altra vantaggio, in particolare per le architetture di microservizi.
Gateway REST di Memphis
Per abilitare la produzione di messaggi tramite chiamate HTTP per vari casi d’uso e facilità di utilizzo, Memphis ha aggiunto un gateway HTTP per ricevere richieste basate su REST (=messaggi) e produrre quei messaggi alla stazione richiesta.
I casi d’uso comuni che traggono vantaggi dal Gateway REST sono:
- Produrre eventi direttamente da un frontend
- Connettere Debezium utilizzando Server HTTP
- Webhook di ArgoCD
- Integrazione di PostHog
- Ricevere dati da Fivetran/Rivery/Ogni piattaforma ETL utilizzando chiamate HTTP
Gateway REST di Memphis + uno schema JSON può essere una potente combinazione per aumentare la qualità dei dati e garantire una comunicazione sana tra applicazioni o servizi.
Memphis supporterà presto anche gRPC.
Conclusion
Infine, vorrei dire che REST è ancora l’architettura più utilizzata e popolare, ed è impossibile abbandonarla. REST presenta diversi svantaggi, come la mancanza di streaming dati, l’assenza di comunicazione bidirezionale, una velocità di esecuzione lenta, ecc., ma è ottima per gli applicazioni standard che incontriamo nella vita quotidiana.
D’altra parte, gRPC, pur essendo giovane e difficile da imparare, offre molte cose come un alto streaming dati su entrambi i lati client e server, una buona comunicazione dati bidirezionale, è veloce e compatto, e utilizza HTTP 2. Grazie alle sue prestazioni veloci, gRPC è ottimale per applicazioni ad alta intensità di lavoro come lo streaming video, lo streaming musicale, i giochi online, il file sharing e le applicazioni di chat.