Che cos'è gRPC?

RPC, o Remote Procedure Call, è un modello di comunicazione per l'interazione client/server che consente alle chiamate remote di apparire e funzionare come chiamate locali. È una tecnica più antica, risalente concettualmente agli anni '70, le cui applicazioni iniziali si sono viste in progetti informatici pionieristici come ARPANET e Xerox PARC.

In una RPC, il client interagisce con una rappresentazione del server che sembra locale ma che in realtà è un intermediario. Questo intermediario viene comunemente definito stub, e gestisce il marshalling e l'unmarshalling dei dati (cioè converte i dati in un formato adatto per la trasmissione e riconvertire i risultati ricevuti dal server nel formato originale). Poiché si tratta di uno stile architettonico per la comunicazione client/server, è comunemente utilizzato nella progettazione delle API.

Esistono molti tipi diversi di framework RPC, tra cui XML-RPC e JSON-RPC. Queste implementazioni, risalenti agli anni '90 e 2000, utilizzano HTTP come protocollo di trasporto, differiscono principalmente nel tipo di formato e hanno dimostrato i punti di forza di RPC: hanno semplificato lo sviluppo, astratto le complessità delle comunicazioni di rete, sono leggere, relativamente semplici da usare e sono leggibili dall'uomo.

Tuttavia, molti ambienti moderni, e in particolare quelli che utilizzano architetture di microservizi, ambienti poliglotti e sistemi con carichi di dati elevati, richiedono un framework più veloce e ad alte prestazioni per connettere le applicazioni distribuite. Idealmente, questo framework facilita un trasferimento di dati più efficiente e in tempo reale tra servizi in esecuzione in ambienti e data center diversi.

gRPC è stato sviluppato per soddisfare questa esigenza, offrendo bassa latenza e alto rendimento attraverso la serializzazione dei dati e il suo utilizzo del protocollo HTTP/2, funzionalità di streaming bidirezionale, generazione di codice e altro ancora.

gRPC è stato inizialmente rilasciato nel 2015, lo stesso anno del rilascio di HTTP/2. Risolve i limiti delle vecchie implementazioni RPC principalmente attraverso l'uso di Protocol Buffers, o Protobuf, il suo linguaggio di definizione dell'interfaccia (IDL). Protobuf serializza e codifica i dati strutturati in formato binario, rendendoli più compatti, consentendo una trasmissione più rapida e prestazioni più elevate.

Protobuf consente inoltre di modificare i campi dati senza interrompere il codice. Ciò consente di ridurre gli errori e di consentire la condivisione e l'elaborazione dei dati in tempo reale. Queste caratteristiche rendono le API create con gRPC una valida opzione per ambienti moderni e distribuiti, architetture di microservizi, applicazioni di streaming e per connettere sistemi e dispositivi Internet of Things.

Se gRPC stesse per "Google Remote Procedure Call", l'acronimo avrebbe senso, ma il team gRPC di grpc.io afferma sfacciatamente che sta per "gRPC Remote Procedure Call". Il suo GitHub spiega che la "g" ha un significato diverso a ogni versione (che va da "gregario" a "goose" a "Guadalupe River Park Conservancy"). In ogni caso, Google ha sviluppato gRPC e lo ha rilasciato come progetto open source nel 2015.

gRPC presenta una versione moderna e aggiornata di RPC, con supporto per i linguaggi moderni e caratteristiche e ottimizzazioni aggiuntive. Le sue funzionalità includono:

• Un linguaggio di progettazione dell'interfaccia (IDL) denominato Protocol Buffers
• Utilizzo di HTTP/2 per la trasmissione dei dati
• Streaming bidirezionale
• Generazione di codice
• Quattro tipi di metodo
• Integrazione con la sicurezza basata su TLS
• Supporto degli intercettori per la registrazione, il tracciamento, l'autenticazione e altro ancora

Protocol Buffers, comunemente noto come Protobuf, è un formato di dati multipiattaforma sviluppato da Google che viene utilizzato per serializzare i dati strutturati. Funge da potente intermediario tra client e server che serializza le richieste in codice binario per la trasmissione.

Questo meccanismo è flessibile ed efficiente e consente allo stesso tempo l'indipendenza dal linguaggio di programmazione, la riduzione delle dimensioni dei messaggi e l'analisi e la trasmissione più rapide. Un'applicazione che usa Java può comunicare con una che usa Python perché la richiesta viene convertita nella lingua franca del binario. Sebbene non sia leggibile dagli esseri umani, il sistema binario è più veloce da trasmettere e decodificare con i computer rispetto a un formato basato su testo come JSON.

In sostanza, gli sviluppatori creano un file di testo con il suffisso ".proto" che contiene tutte le informazioni sulla struttura dei dati. Queste informazioni sono basate su schemi, il che significa che definiscono parametri, metodi e possibili output, una descrizione della struttura dei dati. Ad esempio, potresti avere una voce per "utente", che specifica che questi dati includeranno "nome", "e-mail" e "pizza preferita".

Secondo la documentazione di Protobuf, è come XML "ma più piccolo, più veloce e più semplice. Una volta definito il modo in cui vuoi strutturare i dati, puoi utilizzare un codice sorgente appositamente generato per scrivere e leggere facilmente i dati strutturati da e verso una varietà di flussi di dati e utilizzando una varietà di linguaggi." In qualità di intermediario, Protobuf consente anche l'installazione di varie misure di autenticazione e sicurezza.

Gli sviluppatori possono utilizzare un compilatore, chiamato Protoc, per generare codice in uno qualsiasi dei diversi linguaggi supportati, tra cui C#, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python e Ruby. Questo codice svolge molte funzioni: in genere include classi o moduli, gestisce la serializzazione in binario e la deserializzazione da binario e astrae le complessità dello scambio di dati. Gli sviluppatori non devono preoccuparsi del packaging di rete, del marshalling, dell'aggiornamento per la compatibilità e l'implementazione: Protobuf penserà a tutto.

Un design basato su schemi di Protobuf consente agli sviluppatori di aggiungere nuovi campi di dati alle strutture esistenti senza rompere l'intero sistema. Inoltre, riduce notevolmente lo sforzo necessario per aggiornare, mantenere e gestire noiose attività relative alle API, come la regolazione del codice precedente dopo l'aggiunta di nuovi campi dati. Detto questo, la configurazione iniziale dei file file .proto può richiedere tempo e impegno.

HTTP/2 è un protocollo di trasporto (cioè un metodo utilizzato da computer e server per scambiare informazioni) che utilizza il formato binario per inviare messaggi, riduce le connessioni TCP e utilizza la compressione dell'intestazione, tutti elementi che contribuiscono a renderlo più veloce ed efficiente rispetto al suo predecessore (HTTP/1.1). Inoltre, consente il multiplexing, ovvero la possibilità di inviare più flussi simultanei su una singola connessione. gRPC utilizza i cosiddetti canali per abilitare più flussi su tali connessioni: i messaggi vengono inviati come frame di dati HTTP/2, ognuno dei quali può contenere più messaggi gRPC.

gRPC offre un flusso bidirezionale, in cui sia il client che il server possono inviare messaggi in modo indipendente in un flusso di lettura/scrittura. Questo metodo consente ogni tipo di flessibilità: un server e un client possono scambiarsi risposte in sequenza oppure un server può attendere la ricezione di tutti i messaggi del cliente prima di rispondere. Questa caratteristica può essere regolata in base alle applicazioni specifiche.

gRPC utilizza uno strumento di compilazione chiamato protoc per generare automaticamente codice client e server in vari linguaggi in base alle definizioni dei servizi e alle strutture dei messaggi definite in un file .proto. I plug-in possono essere utilizzati per estendere il supporto a molti altri linguaggi.

Protoc genera classi di accesso ai dati nel linguaggio definito nella definizione proto. Queste classi forniscono semplici funzioni di accesso per campi come [nome], oltre a metodi per serializzare e analizzare la struttura da e verso byte grezzi.¹

gRPC supporta quattro diversi tipi di metodi per la trasmissione dei dati: unario, streaming lato client, streaming lato server e streaming bidirezionale.

gRPC ha un'integrazione integrata con TLS (transport layer security), che crittografa gli scambi di dati tra client e server e consente agli utenti di proteggere le connessioni.

gRPC supporta l'autenticazione collegabile, il tracciamento, la registrazione, le metriche, il bilanciamento del carico, il controllo del stato di salute e altro ancora. 

gRPC dispone di quattro diversi tipi di metodi, che indicano il modo in cui un messaggio viene inviato e ricevuto da un client gRPC e da un server gRPC. Questi tipi sono:

Unario: una chiamata semplice in cui un client invia una singola richiesta e un server risponde con una singola risposta.

Streaming lato server: una chiamata in cui un cliente invia una richiesta, ma il server risponde con più risposte.

Streaming lato client: una chiamata in cui un cliente invia più richieste e un server risponde con un'unica risposta. Il server può scegliere di attendere l'interruzione dell'intero flusso di richieste client prima di elaborare e rispondere.

Streaming bidirezionale: il client e il server inviano entrambi più chiamate avanti e indietro contemporaneamente, consentendo la comunicazione in tempo reale.

Sia gRPC che REST sono stili architettonici comunemente usati nella progettazione delle API. Hanno molte somiglianze: entrambi seguono un'architettura client/server, si basano sulla comunicazione basata su HTTP, sono stateless e indipendenti dal linguaggio, ma differiscono anche in modi chiave che li rendono adatti a diversi casi d'uso.

Formato dei dati: le API REST usano formati di testo normale, ad esempio JSON e XML. gRPC utilizza Protobuf per codificare i dati in formato binario.

Schema di comunicazione: gRPC supporta quattro metodi: unario, streaming server, streaming client e streaming bidirezionale. REST utilizza un sistema unario di richiesta e risposta.

Generazione di codice: gRPC offre la generazione di codice integrata; REST non lo fa, anche se sono disponibili plug-in.

Modello di progettazione: gRPC ha un design orientato ai servizi, in cui le operazioni del server richiamabili sono definite come servizi o funzioni. In REST, la progettazione è orientata alle risorse, in cui i metodi HTTP vengono utilizzati per accedere alle risorse del server tramite endpoint definiti da URL.

Protocollo: gRPC utilizza HTTP/2, mentre REST si basa su HTTP/1.1.

Accoppiamento: il client e il server di gRPC sono strettamente collegati, il che significa che sia il client che il server devono avere accesso allo stesso file di prototipazione middleware. Qualsiasi cambiamento in uno richiede un cambiamento nell'altro. REST è accoppiato in modo libero. Questa indipendenza significa che le modifiche in un componente non influiscono sull'altro.

gRPC viene spesso usato per API complesse che connettono più servizi in un ambiente distribuito. La sua capacità di streaming in tempo reale e le alte prestazioni rendono gRPC adatto a diversi casi d'uso, tra cui microservizi, streaming e connessione di client Internet of Things.

Grazie alle sue alte prestazioni, alla bassa latenza, alla capacità di gestire grandi volumi di dati e alla capacità di streaming bidirezionale in tempo reale, gRPC viene spesso utilizzato per creare API per microservizi.

Poiché gRPC è indipendente dal linguaggio, può consentire la comunicazione tra servizi scritti in linguaggi di programmazione diversi. Inoltre, le definizioni di Protobuf forniscono uno schema fortemente tipizzato che aiuta a salvaguardare l'integrità dei dati del microservizio.

Le funzionalità di streaming bidirezionale di gRPC significano che può trasmettere contemporaneamente i dati in entrambe le direzioni tra client e server su un'unica connessione di rete. Questa funzionalità rende gRPC ideale per processi continui, come le videoconferenze o quando un utente desidera utilizzare parte di un set di dati mentre vengono trasferiti altri dati.

L'Internet of Things è una rete di dispositivi o client connessi. I dispositivi IoT, noti anche come "oggetti smart", possono includere semplici dispositivi di "smart home" come i termostati intelligenti, dispositivi indossabili come smartwatch e abbigliamento con tecnologia RFID, e macchinari industriali e sistemi di trasporto complessi.² Le API gRPC vengono spesso utilizzate per facilitare lo scambio coerente di dati tra questi dispositivi.

Con il suo supporto per lo streaming bidirezionale e le funzionalità ottimizzate per i microservizi (e il suo status di progetto CNCF), gRPC viene sempre più utilizzato per le API cloud-native.

gRPC viene utilizzato per generare librerie client in molti linguaggi di programmazione diversi. Queste librerie vengono generate in base alla definizione del servizio fornita in file .proto. Una volta definito il servizio, gRPC genera automaticamente il codice client in un linguaggio di programmazione scelto.

Questa funzionalità semplifica il lavoro degli sviluppatori, consentendo loro di concentrarsi sulla logica delle applicazioni anziché sul codice di comunicazione di basso livello.

gRPC offre molti vantaggi per le organizzazioni e gli sviluppatori che creano API con requisiti di alte prestazioni. Questi vantaggi includono:

Trasmissione più rapida ed efficiente: ci sono diversi fattori che contribuiscono alle alte prestazioni di gRPC. Per prima cosa, la serializzazione Protobuf riduce le dimensioni dei messaggi e i pacchetti più piccoli possono essere trasmessi più rapidamente. Il file binario viene anche analizzato in modo più efficiente rispetto ai formati di testo normale come JSON o XML.

Inoltre, utilizza HTTP/2, che è più veloce ed efficiente di HTTP/1.1, riducendo ulteriormente la latenza e l'utilizzo della larghezza di banda.

Maggiore portabilità: poiché gRPC utilizza buffer di protocollo (un meccanismo di serializzazione indipendente dal linguaggio e dalla piattaforma) per descrivere le strutture di dati e le interfacce RPC, può essere utilizzato per consentire la comunicazione tra servizi scritti in varie lingue su piattaforme diverse.

Errori di runtime ridotti: Protobuf fornisce una tipizzazione forte, il che significa che applica una struttura di dati solida ed esplicitamente definita. La tipizzazione forte favorisce la coerenza e il rilevamento precoce degli errori, riducendo la possibilità di errori in fase di esecuzione.

Personalizzazione flessibile: il supporto integrato per il middleware consente la personalizzazione e l'aggiunta di funzionalità, come misure di sicurezza e autenticazione o analytics.

Sebbene gRPC abbia molti vantaggi, non è privo di sfide. In alcuni casi, ad esempio le API pubbliche con origini dati semplici in cui la facilità d'uso è una considerazione primaria, la complessità introdotta da gRPC potrebbe non essere necessaria. Le sfide della gRPC includono:

Complessità: definire strutture di messaggi e servizi nei file .proto, come richiede gRPC, può essere più difficile rispetto a lavorare con formati basati su testo come XML e JSON.

Facilità d'uso: gRPC, i buffer di protocollo e HTTP/2 possono presentare una curva di apprendimento ripida per gli sviluppatori abituati a lavorare con REST.

Debug: ispezionare, eseguire il debug e registrare le applicazioni gRPC può essere difficile perché il formato binario non è leggibile dall'uomo. Esistono strumenti in grado di convertire il formato binario, ma richiedono un passaggio in più rispetto a XML o JSON.

Attualità e supporto: gRPC non è vecchio come altri stili di architettura popolari, per esempio REST, e non ha ancora una community ampia o lo stesso supporto per il plug-in e la documentazione. Trattandosi di un framework più recente, per gRPC sono disponibili meno strumenti (ad esempio gli scanner di sicurezza) rispetto ad alcuni stili più consolidati.

Limitazioni dei browser: poiché i browser web non supportano nativamente il protocollo gRPC, non è possibile chiamare direttamente un servizio gRPC da un'applicazione basata su browser. Un modo per ovviare a questo problema è utilizzare un proxy come gRPC-Web.gRPC-Web agisce essenzialmente come un livello di traduzione tra il protocollo HTTP e gRPC di un browser.

L'applicazione web avvia una chiamata gRPC utilizzando la libreria client JavaScript gRPC-Web per inviare una richiesta gRPC adattata per la compatibilità del browser. La richiesta viene inviata a un server proxy che la converte in una richiesta gRPC standard e la inoltra al server back-end gRPC. Il server gRPC elabora la richiesta, invia una risposta al server proxy che la converte nuovamente in formato gRPC-Web prima di restituirla al client.