grpc un primo contatto

in Architetture Software, Informatica

gRpc un primo contatto

Reading Time: 3 minutes

REST è un attore importante per la creazione di servizi di comunicazione tra applicazioni e negli anni è diventato un meccanismo fondamentale per lo scambio dei dati.

L’ecosistema REST basa il suo funzionamento sullo scambio di messaggi e, sebbene sia possibile utilizzare messaggi con formati custom, nel corso degli anni il formato JSON è diventato una sorta di standard. JSON come è noto è un formato di scambio testuale, che ha sostituito in molti contesti XML, diminuendo sensibilmente il payload dello scambio dei dati.

XML , infatti, utilizza una sintassi che necessità l’apertura e la chiusura di tag, che aumentano la dimensione del messaggio scambiato.

Anche con JSON si possono verificare problemi di prestazioni dovuti alla dimensione troppo elevata del messaggio e si può ricorrere a meccanismi di compressione, snaturando però il formato testuale originale.

In questo scenario, sta prendendo piede un nuovo meccanismo di comunicazione chiamato GRPC. Si tratta di un framework per l’invocazione di procedure remote (un pò tutti ricordiamo le RPC 🙂 ) altamente performante ed interoperabile.

Introduzione

Il progetto ha avuto origine all’interno dei laboratori di Google per poi essere distribuito sotto licenza opensource. Come avveniva con le RPC, gRPC consente ad un’applicazione client di eseguire metodi e procedure remote come se fossero delle chiamate locali, il tutto con l’intento di semplificare l’iterazione tra servizi differenti e/o microservices.

Come avviene con REST che utilizza JSON per la comunicazione, gRPC utilizza Protocol Buffers. E’ da notare che Protocol Buffers è stato scelto come meccanismo predefinito per la comunicazione, ma è anche possibile utilizzare altri sistemi, come lo stesso JSON.

Altra caratteristica che lo differenzia da REST è il protocollo di comunicazione utilizzato, che in questo è caso è HTTP/2 , la naturale evoluzione dell’ormai collaudato HTTP/1.

Il protocollo Http/1utilizza per lo scambio dati pacchetti una struttura con diversi campi opzionali, rendendo il pacchetto utilizzato complesso e di dimensioni elevate. Inoltre, lo scaricamento dei contenuti di una pagina web è il risultato dello scaricamento di ogni singolo elemento che la compone (file javascript, immagini, ecc…) aumentando le richieste ed il tempo di risposta dei server web coinvolti. Questi sono solo alcuni dei problemi relativi all’utilizzo del protocollo HTTP/1. Per un’introduzione alle novitià introdotte dalla nuova versione del protocollo si rimanda al post.

Protocol Buffers

E’ il protocollo utilizzato per la comunicazione in gRPC e consente di definire i servizi remoti. Le sue caratteristiche lo rendono particolarmente versatile:

  • non ha alcuna dipendenza con la piattaforma
  • in rete è presente una ricca documentazione
  • è indipendende dal linguaggio di programmazione utilizzato
  • può anche essere utilizzato all’interno di data-storage, oltre che per la comunicazione

Protocol Buffer è l’ IDL (Interface Definition Language) utilizzato per definire l’interfaccia dei servizi remoti, un pò come una sorta di file Xml in cui vengono definite le specifiche da utilizzare.

Con Protocol Buffers viene definita la struttura dei dati che devono essere serializzati. Questa definizione avviene utilizzando un file con estensione .proto, che altro non è che un file di testo. La struttura di questo file è organizzata a messaggi: ogni messaggio è un record composto da una serie di campi. Il compilatore protoc consente di analizzare i file .proto e generare il codice per la gestione delle strutture precedentemente definite nel linguaggio di programmazione preferito. Nell’esempio seguente, all’interno del file person.proto è definita la struttura che definisce una Person, composta da un Id, FirstName e Lastname.

message Person {
    int23 id = 1;
    string firstName = 2;
    string lastName = 3;
}

La parola chiave message, consente di definire un messaggio (in pratica un record). Sempre all’interno del file .proto è possibile definire l’interfaccia del servizio (in pratica, come sarà possibile richiamare da remoto la funzione gRPC), ed i messaggi da utilizzare per la request e quelli della response:

//HelloWorldService .
service HelloWorldService {
   rpc sayHello(HelloRequest) returns (HelloReply) {}
}
// Il messaggio di richiesta contiene il nome.
message HelloRequest {
  string name = 1;
}
// Il messaggio di risposta contiene il saluto.
message HelloReply {
  string greeting = 1;
}

Nell’esempio, il servizio HelloService accetta in ingresso un messaggio di tipo HelloRequest (il nome di tipo stringa) e ritorna un messaggio di tipo HelloReplay (la risposta di tipo stringa).

Alcune considerazioni

L’obiettivo di questo post è quello di essere un’introduzione a gRPC che verrà analizzato (nella versione per dotnet core) in un prossimo post.

Riassumento le caratteristiche fondamentali di gRPC:

  • l’interfaccia del servizio viene definita utilizzando un file .proto
  • gRPC consente di eseguire localmente funzioni remote
  • le operazioni remote possono essere invocate in maniera sincrona (bloccanti) o asincrona (non bloccanti)
  • è possibile utilizzare l’autenticazione
  • è possibile definire un timeout entro il quale la chiamata remota dovrà essere interorrota