La maggior parte delle applicazioni software deve essere in grado di connettersi ad altro codice per diversi motivi. Si può trattare di qualsiasi cosa, dall'integrazione all'aggiunta di nuove funzionalità. Per assicurarsi che il software possa collegarsi ad altre applicazioni e per garantire la sua integrazione in altri programmi, gli sviluppatori utilizzano le API. Per questo motivo, per la maggior parte dei software è necessaria un'interfaccia di programmazione delle applicazioni. Grazie al loro ruolo di ponte tra i sistemi, le API consentono di accedere a una serie di servizi web. Pertanto, è importante scegliere la tecnologia appropriata per offrire un'API al proprio progetto.
Qualsiasi organizzazione che voglia condividere la propria applicazione o piattaforma con i propri utenti deve utilizzare le API. Esistono molti modi per sviluppare e perfezionare le API in modo da renderle perfette per la vostra applicazione. Uno dei metodi più recenti utilizzati dai programmatori per progettare le API è gRPC. Vediamo cos'è gRPC e i suoi pro e contro.
Che cos'è gRPC?
gRPC sta per Google Remote Procedure Call. gRPC è un framework RPC open-source utilizzato per creare API scalabili e veloci. Consente lo sviluppo di sistemi in rete e la comunicazione aperta tra gRPC applicazioni client e server. gRPC è stato adottato da numerose aziende tecnologiche di alto livello, tra cui Google, IBM, Netflix e altre. Il framework gRPC dipende da stack tecnologici all'avanguardia come HTTP/2, buffer di protocollo e altro ancora per una protezione ottimale delle API, chiamate di procedure remote ad alte prestazioni e scalabilità.
Cosa sono RPC?
RPC e REST - Representational State Transfer- sono stati storicamente due approcci separati alla costruzione di API. Inoltre, anche protocolli come SOAP e GraphQL sono utilizzati a questo scopo. Le chiamate di procedura remote consentono di scrivere software come se venisse eseguito localmente, anche se potrebbe essere eseguito su un dispositivo diverso.
Sono il framework più convenzionalmente usato per progettare le API. A differenza di una tipica chiamata al protocollo HTTP, una RPC impiega una chiamata di funzione come metodo principale di interazione tra client e server. RPC è una tecnica produttiva per la creazione di API, poiché gli scambi sono semplici e i contenuti sono leggeri. Anche i servizi di gRPC imitano questa architettura di comunicazione. RPC impiega IDL - Interface Definition Language per contrattare il tipo di dati e i metodi che verranno invocati. I servizi gRPC adottati dalle RPC sono diventati molto popolari negli ultimi anni.
Perché sono stati sviluppati i servizi gRPC?
Man mano che un numero sempre maggiore di aziende apre canali di integrazione, diventa difficile collegare tali software. RPC Le API sono difficili da integrare e rischiose da distribuire perché possono rivelare specifiche interne. Sono sviluppate in molti linguaggi di programmazione e sono strettamente legate al framework sottostante.
Questo problema è stato affrontato e l'accessibilità delle API è aumentata con il lancio dell'API REST nel 2000. In particolare, ha fornito agli utenti un modo coerente per recuperare informazioni indirettamente attraverso le risorse utilizzando tecniche HTTP standard come GET, PUT, POST e altre. La principale distinzione di RPC da REST API è che con RPC vengono affrontati i processi, ma non è facile prevedere quali potrebbero essere i processi nei vari sistemi.
REST API non ha potuto sostituire completamente il semplice e leggero RPC perché produceva una grande quantità di metadati, pur offrendo un formato migliorato per gestire molte applicazioni. Questo ha portato alla nascita dei servizi GraphQL di Facebook e gRPC di Google.
Google ha creato gRPC nel 2015 come aggiunta al framework RPC per collegare numerose architetture di microservizi realizzate con varie tecniche. gRPC era originariamente strettamente legato all'infrastruttura principale di Google, ma alla fine è stato reso open source e standardizzato per l'uso da parte del pubblico generale.
Panoramica dei concetti di gRPC
L'utilizzo di tecnologie all'avanguardia, che hanno prestazioni elevate rispetto a JSON e XML e offrono una maggiore integrità delle API, è responsabile della creazione e della popolarità di gRPC. Alcuni dei concetti di gRPC che si dovrebbero conoscere sono:
Buffer di protocollo
I buffer di protocollo, noti anche come Protobuf, sono standard di serializzazione o deserializzazione che semplificano la definizione delle applicazioni e la generazione automatica del codice delle librerie client. La versione più recente, proto3, è più semplice da usare e offre le nuove funzionalità di gRPC.
.Proto I file abilitano i servizi di gRPC e le comunicazioni tra i client di gRPC e i messaggi del server. Il file .proto viene caricato in memoria al momento dell'esecuzione dal compilatore Protobuf - protoc. Questo compilatore costruisce applicazioni client gRPC e server gRPC che utilizzano la struttura in memoria per serializzare e deserializzare i dati binari. Ogni comunicazione viene inviata e ricevuta tra l'utente e il servizio remoto dopo la generazione del codice in gRPC.
Poiché i dati vengono tradotti in forma binaria e i segnali criptati sono più piccoli, il parsing con Protobuf utilizza meno potenza CPU per gRPC. Pertanto, anche su computer con una CPU debolezza, come i telefoni cellulari, i messaggi vengono inviati più rapidamente con gRPC.
HTTP/2
gRPC Il servizio è costruito su HTTP/2, la versione di HTTP/1.1 che ha meno limitazioni. Sebbene funzioni con il vecchio protocollo HTTP, HTTP/2 presenta diverse caratteristiche sofisticate per gRPC. Tra queste, un livello di framing binario, che divide ogni query e risposta HTTP/2 in messaggi più piccoli e li incornicia in formato binario per migliorare la consegna dei messaggi. Inoltre, gRPC supporta richieste e risposte multiple da parte del client e del server gRPC in streaming bidirezionale full-duplex.
HTTP/2 dispone di un metodo di controllo del flusso che consente di controllare con precisione il tempo RAM necessario per bufferizzare i pacchetti in volo. Offre inoltre la compressione delle intestazioni per i servizi gRPC. In HTTP/2 tutto viene crittografato prima della trasmissione, anche le intestazioni, che forniscono chiamate di procedure remote ad alte prestazioni. gRPC fornisce un'elaborazione sia asincrona che sincrona con HTTP/2, consentendo l'esecuzione di vari tipi di RPC interattivi e in streaming.
Con l'aiuto di tutte queste caratteristiche di HTTP/2, i servizi di gRPC possono utilizzare meno risorse, il che porta a tempi di risposta più rapidi tra le applicazioni basate su cloud e i servizi di gRPC e a una maggiore durata della batteria per i client di gRPC che operano su dispositivi mobili.
Streaming
Un'idea cruciale supportata da gRPC è lo streaming, che consente l'esecuzione di diversi processi all'interno di una singola richiesta. gRPC rende questo possibile grazie alla funzione di multiplexing di HTTP/2, che consente di inviare o ricevere simultaneamente diverse risposte o richieste su una TCP - Transmission Control Protocol - connessione. I principali formati di streaming sono RPC in streaming sul server, RPCstreaming sul client e RPCstreaming bidirezionale.
Canali
A differenza dei flussi HTTP/2, che consentono numerosi flussi simultanei su una singola richiesta di connessione, un canale con gRPC supporta flussi multipli e continui su più richieste. Sono utilizzati per costruire uno stub client e fornire un meccanismo per collegarsi a un server gRPC su un IP e una porta specifici.
gRPC Architettura
L'architettura di gRPC consiste in un client gRPC e in un server gRPC. Ogni servizio client gRPC contiene uno stub o un file generato automaticamente, simile a un'interfaccia che contiene i processi remoti attivi. Il client gRPC avvia una chiamata di procedura locale a uno stub contenente gli argomenti da inoltrare ai messaggi del server gRPC. Lo stub del client gRPC invia quindi la richiesta all'unità client-time locale sul computer locale, dopo aver serializzato gli argomenti utilizzando la procedura di marshaling Protobuf.
Il sistema operativo utilizza il protocollo HTTP/2 per comunicare con il computer server distante. Il sistema operativo del server accetta i messaggi e invoca il processo stub del server, che utilizza Protobuf per invocare l'operazione appropriata dopo aver decodificato i parametri in arrivo. Il livello di trasporto del client riceve quindi la risposta crittografata dallo stub del server. L'esecuzione torna al chiamante dopo che lo stub client gRPC riceve i messaggi di risposta e decodifica gli argomenti forniti.
I vantaggi di gRPC
gRPC presenta diversi vantaggi rispetto ad altri meccanismi di progettazione delle API. gRPC migliora inoltre la struttura di RPC. Ecco i principali vantaggi dei servizi di gRPC:
- Chiamate di procedura remota ad alte prestazioni
Utilizzando Protobuf e HTTP/2, i servizi di gRPC forniscono prestazioni fino a 10 volte superiori e protezione API rispetto alle interazioni REST+JSON. Grazie all'uso di push del server, multiplexing e compressione delle intestazioni, HTTP/2 fornisce classifiche ad alte prestazioni per i servizi gRPC. Mentre il multiplexing elimina il ritardo di testa della linea, il server push consente a HTTP/2 di inviare materiale dal server al client prima che sia necessario. I messaggi sono compressi in modo più efficace con HTTP/2, il che si traduce in un caricamento più rapido con i servizi di gRPC.
- Streaming
La descrizione del servizio per i servizi di streaming di gRPC include già principi di streaming client o server-end. La creazione di client gRPC e di servizi di streaming ne risulta notevolmente semplificata.
- Generazione del codice
La generazione di codice per i programmi client gRPC e server gRPC è il componente chiave dell'approccio web gRPC. Per la generazione del codice dal file .proto, i moduli gRPC utilizzano il compilatore .protoc. Il formato Protobuf è controllato attraverso la generazione di codice in gRPC, che viene utilizzato per definire sia i formati dei dati che gli endpoint delle applicazioni. Può creare stub di rete lato client e scheletri lato server, riducendo così il tempo necessario per progettare programmi con una varietà di servizi in gRPC services.
- Interoperabilità
Numerosi sistemi e linguaggi di programmazione, come Java, Ruby, Go, C# e altri ancora, sono supportati dalle risorse e dalle librerie di gRPC. Con questi linguaggi di programmazione, gli sviluppatori possono creare applicazioni performanti utilizzando la completa compatibilità multipiattaforma con gRPC. Questo grazie alla forma di cablaggio binario di Protobuf e alla generazione di codice efficace per quasi tutti i sistemi.
- La sicurezza
La sicurezza delle API è garantita in gRPC utilizzando HTTP/2 su una sessione crittografata end-to-end TLS. gRPC promuove l'adozione di SSL/TLS per la crittografia dei dati e l'autenticazione tra il server e il client gRPC.
- Produttività e usabilità
Poiché gRPC è un'alternativa completa a RPC, funziona senza problemi su un'ampia gamma di sistemi e linguaggi. gRPC dispone inoltre di un ottimo tooling, grazie al quale molto del codice boilerplate necessario viene generato manualmente. Gli ingegneri possono ora concentrarsi maggiormente sulle funzionalità principali, grazie al notevole risparmio di tempo ottenuto con gRPC.
Contro gRPC
Anche se possiamo sperare che gli inconvenienti di gRPC vengano risolti, essi pongono alcuni problemi al suo utilizzo attuale. Alcuni svantaggi di gRPC di cui si dovrebbe essere consapevoli sono:
- Mancanza di maturità
Lo sviluppo di una tecnologia può essere una barriera significativa all'adozione. Questo è chiaro anche quando si usa gRPC. GraphQL Uno dei peer di gRPC ha più di 14k query su StackOverflow, mentre gRPC ne ha solo un po' meno di 4k al momento. La comunità di gRPC non conosce le migliori pratiche, le soluzioni e i successi perché non c'è molta assistenza da parte dei programmatori per HTTP/2 e per i buffer di protocollo al di fuori di Google. Tuttavia, man mano che la comunità di gRPC si espande e attira nuovi sviluppatori, la situazione si evolverà.
- Supporto limitato per i browser
Poiché nessun browser gRPC attuale è in grado di gestire i frame HTTP/2, non è possibile richiamare efficacemente un servizio gRPC da un browser, poiché gRPC Web dipende principalmente da HTTP/2. Di conseguenza, è necessario utilizzare il servizio HTTP/2. Di conseguenza, è necessario utilizzare un proxy con gRPC, il che comporta diversi svantaggi.
- Illeggibile per l'uomo
A differenza di XML e JSON, i file di Protobuf non sono leggibili dall'uomo perché i dati sono compressi in un formato binario. Gli sviluppatori devono utilizzare strumenti aggiuntivi, come il protocollo di riflessione del server e il prompt dei comandi di gRPC per valutare i payload, effettuare la risoluzione dei problemi e creare query manuali.
- Curva di apprendimento ripida
Ci vorrà un po' di tempo per familiarizzare con i buffer di protocollo e scoprire i metodi per gestire gli attriti di HTTP/2, a differenza di REST e GraphQL, che utilizzano principalmente JSON.
Come può aiutare AppMaster?
No-code generation sta cambiando il modo in cui le persone vedono la programmazione. No-code generation permette di imparare e creare software più velocemente grazie alla generazione di codice. La generazione di codice per la vostra applicazione è più semplice utilizzando no-code piattaforme di generazione come AppMaster. Non ci sono nemmeno problemi di proprietà, perché la generazione del codice è protetta e il codice creato appartiene solo a voi. Con AppMaster è possibile creare applicazioni client e server in modo più semplice e veloce.
La piattaforma di generazione no-code di AppMaster consente agli sviluppatori di utilizzare il protocollo gRPC per effettuare richieste tra architetture di microservizi backend. L'anno prossimo estenderemo il supporto di gRPC includendo le API per le applicazioni gRPC Web e gRPC Mobile.
Conclusione
Sebbene i servizi gRPC presentino numerosi vantaggi che li rendono interessanti per le aziende e gli sviluppatori, alla fine la decisione di utilizzare i servizi gRPC rispetto ad altri come REST o SOAP dipende dall'applicazione. Mentre alcuni software avranno benefici ad alte prestazioni con gRPC, altri potrebbero essere più adatti alle sue alternative. È necessario comprendere gli svantaggi e i vantaggi dei servizi gRPC e decidere se sono adatti alle proprie esigenze.
