GRPC-services vergelijken met HTTP-API's

Door James Newton-King

In dit artikel wordt uitgelegd hoe gRPC-services zich verhouden tot HTTP-API's met JSON (inclusief ASP.NET Core-web-API's). De technologie die wordt gebruikt om een API voor uw app te bieden, is een belangrijke keuze en gRPC biedt unieke voordelen vergeleken met HTTP-API's. In dit artikel worden de sterke en zwakke punten van gRPC besproken en worden scenario's aanbevolen voor het gebruik van gRPC ten opzichte van andere technologieën.

High-level comparison

De volgende tabel biedt een vergelijking op hoog niveau van functies tussen gRPC en HTTP-API's met JSON.

gRPC strengths

Performance

gRPC-berichten worden geserialiseerd met Protobuf, een efficiënte binaire berichtindeling. Protobuf serialiseert zeer snel op de server en client. Protobuf-serialisatie resulteert in kleine nettoladingen van berichten, belangrijk in scenario's met beperkte bandbreedte, zoals mobiele apps.

gRPC is ontworpen voor HTTP/2, een belangrijke revisie van HTTP die aanzienlijke prestatievoordelen biedt ten opzichte van HTTP 1.x:

• Binaire lijsten en compressie. HET HTTP/2-protocol is compact en efficiënt in verzenden en ontvangen.
• Multiplexing van meerdere HTTP/2-aanroepen via één TCP-verbinding. Multiplexing elimineert kop-van-lijnblokkering.

HTTP/2 is niet exclusief voor gRPC. Veel aanvraagtypen, waaronder HTTP-API's met JSON, kunnen HTTP/2 gebruiken en profiteren van de prestatieverbeteringen.

Code generation

Alle gRPC-frameworks bieden eersteklas ondersteuning voor het genereren van code. Een kernbestand voor gRPC-ontwikkeling is het .proto bestand, dat het contract van gRPC-services en -berichten definieert. Vanuit dit bestand genereren gRPC-frameworks een servicebasisklasse, berichten en een volledige client.

Door het bestand tussen de server en de client te delen, kunnen berichten en clientcode van het ene naar het .proto andere worden gegenereerd. Het genereren van code van de client elimineert duplicatie van berichten op de client en server en maakt een sterk getypte client voor u. Het schrijven van een client bespaart aanzienlijke ontwikkelingstijd in toepassingen met veel services.

Strict specification

Er bestaat geen formele specificatie voor http-API met JSON. Ontwikkelaars debatteren over de beste indeling van URL's, HTTP-werkwoorden en antwoordcodes.

De gRPC-specificatie is prescriptief over de indeling die een gRPC-service moet volgen. gRPC elimineert debat en bespaart ontwikkelaarstijd omdat gRPC consistent is tussen platforms en implementaties.

Streaming

HTTP/2 biedt een basis voor langlevende, realtime communicatiestromen. gRPC biedt eersteklas ondersteuning voor streaming via HTTP/2.

Een gRPC-service ondersteunt alle streamingcombinaties:

• Unary (geen streaming)
• Server naar clientstreaming
• Client naar serverstreaming
• Bi-directional streaming

Deadline/time-outs en annulering

met gRPC kunnen clients opgeven hoe lang ze bereid zijn te wachten totdat een RPC is voltooid. De deadline wordt naar de server verzonden en de server kan bepalen welke actie moet worden ondernomen als deze de deadline overschrijdt. De server kan bijvoorbeeld gRPC-/HTTP-/databaseaanvragen tijdens time-out annuleren.

Het doorgeven van de deadline en annulering via onderliggende gRPC-aanroepen helpt bij het afdwingen van resourcegebruikslimieten.

aanbevolen gRPC-scenario's

gRPC is geschikt voor de volgende scenario's:

• Microservices: gRPC is ontworpen voor communicatie met lage latentie en hoge doorvoer. gRPC is ideaal voor lichtgewicht microservices waarbij efficiëntie essentieel is.
• Point-to-point realtime communicatie: gRPC biedt uitstekende ondersteuning voor bidirectionele streaming. gRPC-services kunnen berichten in realtime pushen zonder polling.
• Polyglot-omgevingen: gRPC-hulpprogramma's ondersteunen alle populaire ontwikkeltalen, waardoor gRPC een goede keuze is voor omgevingen met meerdere talen.
• Netwerkbeperkingsomgevingen: gRPC-berichten worden geserialiseerd met Protobuf, een lichtgewicht berichtindeling. Een gRPC-bericht is altijd kleiner dan een equivalent JSON-bericht.
• Communicatie tussen processen (IPC): IPC-transporten zoals Unix-domeinsockets en benoemde pijpen kunnen worden gebruikt met gRPC om te communiceren tussen apps op dezelfde computer. Zie Communicatie tussen processen met gRPCvoor meer informatie.

gRPC weaknesses

Beperkte browserondersteuning

Het is onmogelijk om vandaag rechtstreeks een gRPC-service aan te roepen vanuit een browser. gRPC maakt intensief gebruik van HTTP/2-functies en geen browser biedt het niveau van controle dat is vereist voor webaanvragen ter ondersteuning van een gRPC-client. Browsers staan bijvoorbeeld niet toe dat een aanroeper vereist dat HTTP/2 wordt gebruikt of toegang bieden tot onderliggende HTTP/2-frames.

gRPC op ASP.NET Core biedt twee browsercompatibele oplossingen:

• met gRPC-Web kunnen browser-apps gRPC-services aanroepen met de gRPC-webclient en Protobuf. gRPC-Web vereist dat de browser-app een gRPC-client genereert. met gRPC-Web kunnen browser-apps profiteren van het hoge prestaties en lage netwerkgebruik van gRPC.

  .NET heeft ingebouwde ondersteuning voor gRPC-Web. Zie gRPC-Web in ASP.NET Core gRPC-apps voor meer informatie.

• met gRPC JSON-transcodering kunnen browser-apps gRPC-services aanroepen alsof ze RESTful API's met JSON waren. De browser-app hoeft geen gRPC-client te genereren of iets te weten te komen over gRPC. RESTful-API's kunnen automatisch worden gemaakt op basis van gRPC-services door aantekeningen te maken op het .proto bestand met HTTP-metagegevens. Met transcodering kan een app ondersteuning bieden voor zowel gRPC- als JSON-web-API's zonder dat de inspanningen voor het bouwen van afzonderlijke services voor beide worden gedupliceerd.

  .NET biedt ingebouwde ondersteuning voor het maken van JSON-web-API's van gRPC-services. Zie gRPC JSON-transcodering in ASP.NET Core gRPC-apps voor meer informatie.

Niet door mensen leesbaar

HTTP-API-aanvragen worden verzonden als tekst en kunnen door mensen worden gelezen en gemaakt.

gRPC-berichten worden standaard gecodeerd met Protobuf. Hoewel Protobuf efficiënt is om te verzenden en te ontvangen, is de binaire indeling ervan niet leesbaar voor mensen. Protobuf vereist dat de interfacebeschrijving van het bericht die in het .proto bestand is opgegeven, correct deserialiseren. Aanvullende hulpprogramma's zijn vereist voor het analyseren van Protobuf-nettoladingen op de kabel en het opstellen van aanvragen met de hand.

Functies zoals serverspiegeling en het opdrachtregelprogramma gRPC bestaan om te helpen bij binaire Protobuf-berichten. Protobuf-berichten ondersteunen ook conversie van en naar JSON. De ingebouwde JSON-conversie biedt een efficiënte manier om Protobuf-berichten te converteren naar en van door mensen leesbare vorm bij foutopsporing.

Alternatieve frameworkscenario's

Andere frameworks worden aanbevolen via gRPC in de volgende scenario's:

• Toegankelijke API's voor browsers: gRPC wordt niet volledig ondersteund in de browser. gRPC-Web kan browserondersteuning bieden, maar het heeft beperkingen en introduceert een serverproxy.
• Realtime communicatie uitzenden: gRPC ondersteunt realtime communicatie via streaming, maar het concept van het uitzenden van een bericht naar geregistreerde verbindingen bestaat niet. In een chatruimtescenario waarin nieuwe chatberichten naar alle clients in de chatruimte moeten worden verzonden, is elke gRPC-oproep vereist om nieuwe chatberichten afzonderlijk naar de client te streamen. SignalR is een nuttig framework voor dit scenario. SignalR heeft het concept van permanente verbindingen en ingebouwde ondersteuning voor het uitzenden van berichten.

Additional resources

• Een .NET gRPC-client en -server maken in ASP.NET Core
• Overzicht van gRPC op .NET
• gRPC-diensten met C#
• gRPC migreren van C-core naar gRPC voor .NET-