Confrontare servizi gRPC e API HTTP

Di James Newton-King

Questo articolo illustra il confronto tra i servizi gRPC e le API HTTP con JSON (incluse le API Web di base ASP.NET). La tecnologia usata per fornire un'API per l'app è una scelta importante e gRPC offre vantaggi univoci rispetto alle API HTTP. Questo articolo illustra i punti di forza e i punti deboli di gRPC e consiglia scenari per l'uso di gRPC su altre tecnologie.

Confronto generale

La tabella seguente offre un confronto generale delle funzionalità tra gRPC e LE API HTTP con JSON.

Punti di forza gRPC

Prestazioni

I messaggi gRPC vengono serializzati usando Protobuf, un formato di messaggio binario efficiente. Protobuf serializza molto rapidamente sul server e sul client. La serializzazione protobuf genera payload di messaggi di piccole dimensioni, importanti in scenari con larghezza di banda limitata come le app per dispositivi mobili.

gRPC è progettato per HTTP/2, una revisione importante di HTTP che offre vantaggi significativi in termini di prestazioni rispetto a HTTP 1.x:

• Frame binario e compressione. Il protocollo HTTP/2 è compatto ed efficiente sia nell'invio che nella ricezione.
• Multiplexing di più chiamate HTTP/2 tramite una singola connessione TCP. Il multiplexing elimina il blocco head-of-line.

HTTP/2 non è esclusivo di gRPC. Molti tipi di richiesta, incluse le API HTTP con JSON, possono usare HTTP/2 e trarre vantaggio dai miglioramenti delle prestazioni.

Generazione codice

Tutti i framework gRPC forniscono supporto di prima classe per la generazione di codice. Un file di base per lo sviluppo gRPC è il .proto file , che definisce il contratto di servizi e messaggi gRPC. Da questo file, i framework gRPC generano una classe di base del servizio, i messaggi e un client completo.

Condividendo il .proto file tra il server e il client, i messaggi e il codice client possono essere generati da end-to-end. La generazione di codice del client elimina la duplicazione dei messaggi nel client e nel server e crea automaticamente un client fortemente tipizzato. Non dover scrivere un client consente di risparmiare tempo di sviluppo significativo nelle applicazioni con molti servizi.

Specifica rigorosa

Non esiste una specifica formale per l'API HTTP con JSON. Gli sviluppatori discotono il formato migliore di URL, verbi HTTP e codici di risposta.

La specifica gRPC è prescrittiva sul formato che deve essere seguito da un servizio gRPC. gRPC elimina il dibattito e consente di risparmiare tempo per gli sviluppatori perché gRPC è coerente tra piattaforme e implementazioni.

Streaming

HTTP/2 offre una base per flussi di comunicazione in tempo reale di lunga durata. gRPC offre il supporto di prima classe per lo streaming tramite HTTP/2.

Un servizio gRPC supporta tutte le combinazioni di streaming:

• Unario (senza streaming)
• Streaming da server a client
• Streaming da client a server
• Streaming bidirezionale

Scadenza/timeout e annullamento

gRPC consente ai client di specificare per quanto tempo sono disposti ad attendere il completamento di una RPC. La scadenza viene inviata al server e il server può decidere quale azione eseguire se supera la scadenza. Ad esempio, il server potrebbe annullare le richieste gRPC/HTTP/database in corso in caso di timeout.

La propagazione della scadenza e dell'annullamento tramite chiamate gRPC figlio consente di applicare i limiti di utilizzo delle risorse.

Scenari consigliati per gRPC

gRPC è particolarmente adatto agli scenari seguenti:

• Microservizi: gRPC è progettato per comunicazioni a bassa latenza e velocità effettiva elevata. gRPC è ideale per microservizi leggeri in cui l'efficienza è fondamentale.
• Comunicazione da punto a punto in tempo reale: gRPC offre un ottimo supporto per lo streaming bidirezionale. I servizi gRPC possono eseguire il push dei messaggi in tempo reale senza eseguire il polling.
• Ambienti poliglotta: gli strumenti gRPC supportano tutti i linguaggi di sviluppo più diffusi, rendendo gRPC una buona scelta per ambienti multi-linguaggio.
• Ambienti vincolati di rete: i messaggi gRPC vengono serializzati con Protobuf, un formato di messaggio leggero. Un messaggio gRPC è sempre più piccolo di un messaggio JSON equivalente.
• Comunicazione tra processi (IPC): i trasporti IPC, ad esempio socket di dominio Unix e named pipe, possono essere usati con gRPC per comunicare tra app nello stesso computer. Per altre informazioni, vedere comunicazione tra processi con gRPC.

Punti deboli gRPC

Supporto limitato del browser

È impossibile chiamare direttamente un servizio gRPC da un browser. gRPC usa molto le funzionalità HTTP/2 e nessun browser fornisce il livello di controllo richiesto sulle richieste Web per supportare un client gRPC. Ad esempio, i browser non consentono a un chiamante di richiedere l'uso di HTTP/2 o di fornire l'accesso ai frame HTTP/2 sottostanti.

gRPC in ASP.NET Core offre due soluzioni compatibili con browser:

• gRPC-Web consente alle app browser di chiamare i servizi gRPC con il client gRPC-Web e Protobuf. gRPC-Web richiede che l'app browser generi un client gRPC. gRPC-Web consente alle app del browser di sfruttare le prestazioni elevate e l'utilizzo ridotto della rete di gRPC.

  .NET include il supporto predefinito per gRPC-Web. Per altre informazioni, vedere gRPC-Web in ASP.NET app gRPC core.

• La transcodifica JSON gRPC consente alle app del browser di chiamare i servizi gRPC come se fossero API RESTful con JSON. L'app browser non deve generare un client gRPC o sapere nulla su gRPC. Le API RESTful possono essere create automaticamente dai servizi gRPC annotando il .proto file con i metadati HTTP. La transcodifica consente a un'app di supportare sia le API Web gRPC che JSON senza duplicare lo sforzo di creare servizi separati per entrambi.

  .NET include il supporto predefinito per la creazione di API Web JSON dai servizi gRPC. Per altre informazioni, vedere transcodifica JSON gRPC nelle app gRPC di ASP.NET Core.

Non leggibile

Le richieste API HTTP vengono inviate come testo e possono essere lette e create dagli esseri umani.

I messaggi gRPC vengono codificati con Protobuf per impostazione predefinita. Mentre Protobuf è efficiente per inviare e ricevere, il formato binario non è leggibile. Protobuf richiede che la descrizione dell'interfaccia del messaggio specificata nel .proto file deserializzi correttamente. Sono necessari strumenti aggiuntivi per analizzare i payload Protobuf in transito e comporre le richieste a mano.

Esistono funzionalità come la reflection server e lo strumento da riga di comando gRPC per facilitare i messaggi binari Protobuf. Inoltre, i messaggi Protobuf supportano la conversione da e verso JSON. La conversione JSON predefinita offre un modo efficiente per convertire i messaggi Protobuf in e da un modulo leggibile durante il debug.

Scenari di framework alternativi

Altri framework sono consigliati su gRPC negli scenari seguenti:

• API accessibili dal browser: gRPC non è completamente supportato nel browser. gRPC-Web può offrire supporto per i browser, ma presenta limitazioni e introduce un proxy server.
• Trasmissione di comunicazioni in tempo reale: gRPC supporta la comunicazione in tempo reale tramite streaming, ma il concetto di trasmissione di un messaggio verso connessioni registrate non esiste. Ad esempio in uno scenario di chat room in cui devono essere inviati nuovi messaggi di chat a tutti i client nella chat room, ogni chiamata gRPC è necessaria per trasmettere singolarmente nuovi messaggi di chat al client. SignalR è un framework utile per questo scenario. SignalR ha il concetto di connessioni persistenti e il supporto predefinito per la trasmissione dei messaggi.

Risorse aggiuntive

• Creare un client e un server gRPC di .NET Core in ASP.NET Core
• Panoramica di gRPC in .NET
• Servizi gRPC con C#
• Eseguire la migrazione di gRPC da C-core a gRPC per .NET