Usare gRPC come infrastruttura per i nostri servizi web

di Morgan Pizzini, in ASP.NET Core 5,

gRPC è un framework RPC (Remote Procedure Call), creato da Google nel 2015. Benchè sia quindi un prodotto relativamente giovane, la comunicazione RPC esiste da moltissimi anni: i suoi principali obbiettivi sono la comunicazione tra vari programmi, eseguiti su macchine diverse e anche in linguaggi diversi, nascondendo tutta l'infrastruttura di comunicazione, in modo che si possano eseguire operazioni come se tutto il codice fosse scritto all'interno dello stesso applicativo.

Nel mondo .NET, prima della supremazia delle API REST, potevamo scegliere di creare un'applicazione basata su SOAP. Infatti SOAP è un protocollo di interscambio che prende spunto da XML-RPC, ossia RPC che per IDL (Interface Description Language - interfaccia per lo scambio dei dati) utilizza lo standard XML. Si trattava tuttavia di un protocollo verboso e a tratti anche complesso, che presentava anche alcuni problemi di interoparabilità tra diverse tecnologie a cause di implementazioni leggermente differenti e incompatibili. Con REST invece si è passati a un concetto di API più semplice e intuitivo, che però ha alcuni limiti dal punto di vista della tipizzazione e delle prestazioni. Questi sono i principali difetti che gRPC si propone di risolvere.

Da .NET Core 3.1, e di conseguenza anche in .NET 5, troviamo tra le possibilità di progetto anche la creazione di un servizio gRPC.

Caratteristiche gRPC

Essendo stato sviluppato negli ultimi anni, gRPC incorpora tutte le ultime richieste dal punto di vista tecnologico: si basa sul protocollo HTTP/2, è leggero, sia in termini di comunicazione, in quanto utilizza una serializzazione binaria attraverso file Protobuf, che a livello applicativo: grazie a parser che consentono di tradurre le definizioni di servizi e contratti in classi tipizzate, come vedremo, l'implementazione consiste praticamente nella scrittura di una classe derivata, all'interno della quale dovremo effettuare l'override di alcuni metodi.

Supporta 4 diversi tipi di comunicazione:

  • Unaria: a seguito di una chiamata da parte del client il server risponde
  • Streaming server: il server, dopo una richiesta, invia varie risposte al client
  • Streaming client: il client, dopo una richiesta, può contattare più volte il server prima di avere risposta
  • Streaming bidirezionale: dopo una chiamata, sia il client che il server possono inviare più messaggi sulla stessa.

La comunicazione si basa su interfacce definite all'interno di un file *.proto. Questi possono essere condivisi tra i vari programmi e linguaggi di programmazione, in quanto sono gli unici di cui gRPC avrà bisogno per stabilire una corretta comunicazione.

syntax = "proto3";

option csharp_namespace = "Negozio";

service Magazzino {
  rpc CreaProdotto (CreaProdottoRequest) returns (CreaProdottoResponse);
}

message CreaProdottoRequest {
  string nome = 1;
  int32 qta = 2;
}

message CreaProdottoResponse {
  string prodottoId = 1;
}

Nello snippet precedente notiamo come, anche se in un linguaggio diverso dal C#, il codice appare comunque molto chiaro: utilizzando una sintassi proto versione 3, dichiariamo un servizio Magazzino che definisce un metodo CreaProdotto. Quest'ultimo richiede in input un oggetto di tipo CreaProdottoRequest con proprietà nome,qta e risponderà con una classe CreaProdottoResponse con proprietà prodottoId.

Le proprietà sono espresse come coppie di chiave-valore, dove il numero aiuta il serializzatore a leggere e scrivere in binario; questo serve a garantire anche compatibilità futura per i client, che sono autonomamente in grado di ignorare i numeri che, da contratto, non sono presenti nella definizione in uso.

Setup progetto .NET

Per lo sviluppo di una libreria che utilizzi le definizioni contenute nei file *.proto, avremo la necessità di includere il pacchetto NuGet Grpc.Tools, il cui compito è di generare le corrispondenti classi C#. Se stiamo realizzando la parte server del servizio, invece, possiamo affidarci a Grpc.AspNetCore che include Grpc.Tools e tutti i requisiti fondamentali per la serializzazione e deserializzazione dei messaggi.

I file *.proto alle volte si riferiscono anche delle funzionalità e classi standard che, come vedremo più in avanti, sono implementate nel pacchetto Google.Protobuf.

6 pagine in totale: 1 2 3 4 5 6
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

Top Ten Articoli

Articoli via e-mail

Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!

In primo piano

I più letti di oggi

In evidenza

Misc