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.

Vergelijking op hoog niveau

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

gRPC-sterke punten

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 genereren

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 .proto bestand tussen de server en de client te delen, kunnen berichten en clientcode van einde tot einde worden gegenereerd. Het genereren van clientcode elimineert de verdubbeling van berichten op zowel de client als de server en maakt een sterk getypte client voor u. Niet hoeven schrijven van een client bespaart aanzienlijke ontwikkelingstijd in toepassingen met veel services.

Strikte specificatie

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
• Bidirectioneel streamen

Deadline/tijdslimieten en annuleringen

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 bij een time-out gRPC-, HTTP- of databaseaanvragen 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-zwakke punten

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 de interfacebeschrijving van het bericht zoals opgegeven in het .proto-bestand teneinde correct te deserialiseren. Aanvullende hulpprogramma's zijn vereist voor het analyseren van Protobuf-payloads tijdens het transport en om verzoeken handmatig samen te stellen.

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.

Aanvullende bronnen

• 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-