De meeste softwaretoepassingen moeten om verschillende redenen verbinding kunnen maken met andere code. Dit kan van alles zijn, van integratie tot het toevoegen van nieuwe functionaliteit. Om ervoor te zorgen dat software aan andere toepassingen kan worden gekoppeld en om de integratie in andere programma's te waarborgen, gebruiken ontwikkelaars API's. Daarom is een Application Programming Interface noodzakelijk voor de meeste software. Door hun rol als brug tussen systemen stellen API's personen in staat toegang te krijgen tot een verscheidenheid aan webdiensten. Daarom is het belangrijk de juiste technologie te kiezen om een API aan uw project aan te bieden.
Elke organisatie die haar applicatie of platform wil delen met haar gebruikers moet API's gebruiken. Er zijn vele manieren om API's te ontwikkelen en te verfijnen zodat ze perfect passen bij uw toepassing. Een van de nieuwste methoden die programmeurs gebruiken om API's te ontwerpen is gRPC. Laten we eens kijken wat gRPC is en wat de voor- en nadelen ervan zijn.
Wat is gRPC?
gRPC staat voor Google Remote Procedure Call. gRPC is een open-source RPC-framework dat wordt gebruikt om schaalbare en snelle API's te maken. Het maakt de ontwikkeling van netwerksystemen en open communicatie tussen gRPC client en server applicaties mogelijk. gRPC is omarmd door verschillende top tech bedrijven, waaronder Google, IBM, Netflix, en meer. Het gRPC framework is afhankelijk van cutting-edge tech stacks zoals HTTP/2, protocol buffers, en meer voor optimale API bescherming, hoogperformante remote procedure calls, en schaalbaarheid.
Wat zijn RPCs?
RPC en REST - Representational State Transfer- zijn historisch gezien twee verschillende benaderingen voor het bouwen van API's. Daarnaast worden hiervoor ook protocollen als SOAP en GraphQL gebruikt. Met Remote procedure calls kunt u software schrijven alsof deze lokaal draait, hoewel deze op een ander apparaat kan draaien.
Zij zijn het meest conventioneel gebruikte kader om API's te ontwerpen. In tegenstelling tot een typische HTTP-protocolaanroep, gebruikt een RPC een functieaanroep als de primaire methode van client-server interactie. RPC is een productieve techniek voor het maken van API's, omdat de uitwisselingen eenvoudig zijn, en de inhoud licht. gRPC diensten bootsen ook deze communicatiearchitectuur na. RPC gebruikt IDL - Interface Definition Language om het gegevenstype en de methoden die zullen worden aangeroepen te contracteren. Aangepaste gRPC diensten van RPC's zijn de laatste jaren erg populair geworden.
Waarom werden gRPC diensten ontwikkeld?
Naarmate meer ondernemingen kanalen voor integratie openen, wordt het steeds moeilijker om dergelijke software te koppelen. RPC API's zijn moeilijk te integreren en riskant om te verspreiden omdat ze interne bijzonderheden kunnen onthullen. Ze worden ontwikkeld in vele programmeertalen en zijn nauw verbonden met het onderliggende kader.
Dit probleem werd aangepakt en de toegankelijkheid van API's werd vergroot toen in 2000 de REST API werd gelanceerd. Het gaf gebruikers met name een consistente manier om informatie indirect op te halen via assets met behulp van standaard HTTP-technieken zoals GET, PUT, POST, en andere. Het primaire onderscheid tussen RPC en REST API is dat met RPC processen worden aangepakt, maar het is niet eenvoudig te voorspellen wat de processen in verschillende systemen zouden kunnen zijn.
De REST API kon het eenvoudige en lichte RPC niet volledig vervangen omdat het een grote hoeveelheid metadata produceerde, ook al bood het een verbeterd formaat voor het omgaan met vele toepassingen. Dit leidde uiteindelijk tot de opkomst van Facebook's GraphQL en Google's gRPC diensten.
Google bouwde gRPC in 2015 als een aanvulling op het RPC-framework om talrijke microservices-architecturen te verbinden die met verschillende technieken waren gemaakt. gRPC was oorspronkelijk nauw verbonden met de kerninfrastructuur van Google, maar werd uiteindelijk open source gemaakt en gestandaardiseerd voor gebruik door het grote publiek.
Overzicht van gRPC concepten
Het gebruik van geavanceerde technologieën, die hogere prestaties leveren dan JSON en XML en een grotere API-integriteit bieden, is verantwoordelijk voor het ontstaan en de populariteit van gRPC. Enkele van de gRPC concepten waarvan u op de hoogte moet zijn, zijn:
Protocolbuffers
Protocol buffers, ook bekend als Protobuf, zijn serialisatie of deserialisatie standaarden die het eenvoudig maken om toepassingen te definiëren en automatisch de code te genereren van client libraries. De meest recente versie, proto3, is eenvoudiger in gebruik en biedt de nieuwste mogelijkheden voor gRPC.
.Proto De bestanden maken de gRPC diensten en de communicatie tussen gRPC clients en serverberichten mogelijk. Het .proto bestand wordt bij uitvoering in het geheugen geladen door de compiler Protobuf - protoc. Deze compiler bouwt gRPC client en gRPC server applicaties die gebruik maken van de in-memory structuur om de binaire gegevens te serialiseren en deserialiseren. Elke communicatie wordt verzonden en ontvangen tussen de gebruiker en de dienst op afstand na het genereren van code in gRPC.
CPU Aangezien de gegevens in een binaire vorm worden vertaald en de gecodeerde signalen kleiner zijn, gebruikt het parsen met Protobuf minder energie voor gRPC. Daarom worden zelfs op computers met een zwakkere CPU, zoals mobiele telefoons, berichten sneller verzonden met gRPC.
HTTP/2
gRPC dienst is gebouwd op HTTP/2, de versie van HTTP/1.1 die minder beperkingen heeft. Hoewel het werkt met het oudere HTTP-protocol, heeft HTTP/2 verschillende geavanceerde functies voor gRPC. Dit omvat een binaire kaderlaag, die elke HTTP/2-vraag en -antwoord in kleinere berichten verdeelt en deze in een binair formaat framet om de levering van berichten te verbeteren. Bovendien ondersteunt gRPC meerdere verzoeken en antwoorden van de client en gRPC server in bidirectionele full-duplex streaming.
HTTP/2 heeft een flow control-methode die een nauwkeurige controle mogelijk maakt van de RAM die nodig is om in-flight pakketten te bufferen. Het biedt ook headercompressie voor gRPC diensten. Alles in HTTP/2 wordt gecodeerd vóór verzending, zelfs headers, die zorgen voor krachtige remote procedure calls. gRPC biedt zowel asynchrone als synchrone verwerking met HTTP/2, waardoor de uitvoering van verschillende interactieve en gestreamde RPC-types mogelijk is.
Met behulp van al deze kenmerken van HTTP/2 kunnen gRPC diensten minder bronnen gebruiken, wat leidt tot snellere reactietijden bij cloudgebaseerde toepassingen en gRPC diensten en een langere batterijduur voor gRPC clients die werken op mobiele apparaten.
Streaming
Een cruciaal idee dat gRPC ondersteunt is streaming, dat de uitvoering van meerdere processen binnen één verzoek mogelijk maakt. gRPC maakt dit mogelijk door de multiplexing-functie van HTTP/2, waarmee meerdere antwoorden of verzoeken tegelijk kunnen worden verzonden of ontvangen via één TCP - Transmission Control Protocol - verbinding. De primaire streamingformaten zijn server-streaming RPC's, client-streaming RPCs, en bidirectioneel-streaming RPCs.
Kanalen
In tegenstelling tot HTTP/2 streams, die meerdere gelijktijdige streams op een enkele verzoekverbinding toestaan, ondersteunt een kanaal met gRPC meerdere continue streams over meerdere verzoeken. Ze worden gebruikt om een client stub te bouwen en geven een mechanisme om een verbinding te maken met een gRPC server op een specifieke IP en poort.
gRPC Architectuur
De gRPC architectuur bestaat uit zowel een gRPC client als een gRPC server. Elke gRPC client service bevat een stub of een automatisch gegenereerd bestand, dat verwant is aan een interface die de actieve processen op afstand bevat. De gRPC client initieert een lokale procedure-aanroep naar een stub met argumenten die moeten worden doorgestuurd naar de gRPC server-berichten. De gRPC client stub stuurt vervolgens de query naar de lokale client-time unit op de lokale computer na serialisatie van de argumenten met behulp van de Protobuf marshaling procedure.
Het besturingssysteem gebruikt het HTTP/2-protocol om te communiceren met de verre servercomputer. Het besturingssysteem van de server accepteert de berichten en roept het server stub proces aan, dat Protobuf gebruikt om de juiste operatie aan te roepen na het decoderen van de binnenkomende parameters. De transportlaag van de client ontvangt vervolgens het versleutelde antwoord van de server stub. De uitvoering gaat terug naar de beller nadat de gRPC client stub de antwoordberichten heeft ontvangen en de verstrekte argumenten heeft uitgepakt.
Voordelen van gRPC
gRPC heeft verscheidene voordelen ten opzichte van andere API-ontwerpmechanismen. gRPC verbetert ook de structuur van RPC. Dit zijn de belangrijkste voordelen van gRPC services:
- Krachtige remote procedure calls
Met behulp van Protobuf en HTTP/2 bieden gRPC diensten tot 10 keer de hoge prestaties en API-bescherming van REST+JSON interactie. Met het gebruik van server pushes, multiplexing en headercompressie biedt HTTP/2 krachtige rankings voor gRPC diensten. Terwijl multiplexing een einde maakt aan head-of-line vertraging, maakt server push het mogelijk voor HTTP/2 om materiaal van de server naar de client te pushen voordat het nodig is. De berichten worden effectiever gecomprimeerd met HTTP/2, wat resulteert in sneller laden met gRPC diensten.
- Streaming
De dienstbeschrijving voor streaming gRPC diensten omvat reeds client- of server-end streamingprincipes. Het bouwen van gRPC clients en streaming services wordt hierdoor aanzienlijk vergemakkelijkt.
- Code generatie
De codegeneratie voor gRPC client- en gRPC serverprogramma's is de belangrijkste component van de gRPC webbenadering. Voor het genereren van code uit het .proto bestand gebruiken gRPC modules de .protoc compiler. Het Protobuf formaat wordt gecontroleerd door codegeneratie in gRPC, die wordt gebruikt om zowel gegevensformaten als toepassingseindpunten te definiëren. Het kan client-side netwerk stubs en server-side skeletons creëren, waardoor het ontwerpen van programma's met een verscheidenheid aan diensten in gRPC services minder tijd kost.
- Interoperabiliteit
Tal van systemen en programmeertalen, zoals Java, Ruby, Go, C#, en meer, worden ondersteund door de gRPC bronnen en bibliotheken. Met deze programmeertalen kunnen ontwikkelaars krachtige apps maken terwijl ze gebruik maken van volledige cross-platform compatibiliteit met gRPC. Dit is te danken aan de Protobuf binaire bedradingsvorm en effectieve codegeneratie voor bijna alle systemen.
- Beveiliging
API-beveiliging wordt in gRPC gegarandeerd door HTTP/2 over een TLS end-to-end versleutelde sessie. gRPC bevordert de toepassing van SSL/TLS voor gegevensversleuteling en authenticatie tussen de server en de gRPC -client.
- Productiviteit en bruikbaarheid
Aangezien gRPC een volledig RPC alternatief is, werkt het probleemloos op een groot aantal systemen en talen. gRPC heeft ook een geweldige tooling, waarbij veel van de noodzakelijke boilerplate-code handmatig wordt gegenereerd. Ingenieurs kunnen zich nu meer concentreren op de kernfunctionaliteit door de aanzienlijke tijdsbesparing met gRPC.
Nadelen gRPC
Hoewel we kunnen hopen dat de nadelen van gRPC uiteindelijk worden opgelost, vormen ze nu toch enkele problemen voor het gebruik ervan. Enkele nadelen van gRPC waarvan u zich bewust moet zijn:
- Gebrek aan maturiteit
De ontwikkeling van een technologie kan een aanzienlijke belemmering vormen voor het gebruik ervan. Dat is ook duidelijk bij het gebruik van gRPC. GraphQL, een van de gelijken van gRPC, heeft meer dan 14k zoekopdrachten op StackOverflow, terwijl gRPC er momenteel slechts iets minder dan 4k heeft. De gRPC gemeenschap mist kennis van best practices, oplossingen en successen omdat er niet veel hulp van programmeurs is voor HTTP/2 en protocol buffers buiten Google. Maar naarmate de gRPC gemeenschap zich uitbreidt en nieuwe ontwikkelaars aantrekt, zal dit uiteindelijk evolueren.
- Beperkte browserondersteuning
Aangezien geen enkele huidige gRPC webbrowser HTTP/2 frames kan verwerken, kunt u een gRPC dienst niet effectief aanroepen vanuit een browser, aangezien gRPC Web voornamelijk afhankelijk is van HTTP/2. Bijgevolg moet u een proxy gebruiken met gRPC, wat verschillende nadelen heeft.
- Onleesbaar voor mensen
In tegenstelling tot XML en JSON zijn Protobuf bestanden niet leesbaar voor mensen, omdat de gegevens worden gecomprimeerd tot een binair formaat. Ontwikkelaars moeten gebruik maken van extra hulpmiddelen, zoals het serverreflectieprotocol en de opdrachtprompt gRPC om payloads te evalueren, problemen op te lossen en handmatige query's te maken.
- Steile leercurve
Het zal een tijdje duren om vertrouwd te raken met protocolbuffers en methoden te ontdekken voor het omgaan met HTTP/2-fricties, in tegenstelling tot REST en GraphQL, die beide meestal JSON gebruiken.
Hoe helpt AppMaster?
No-code generatie verandert de manier waarop mensen tegen programmeren aankijken. No-code generatie maakt het mogelijk voor mensen om sneller software te leren en te maken met codegeneratie. Code generatie voor uw applicatie is eenvoudiger met behulp van no-code generatie platforms zoals AppMaster. Er zijn ook geen eigendomskwesties, aangezien de codegeneratie beschermd is, en de code die u creëert uitsluitend aan u toebehoort. U kunt sneller en eenvoudiger client- en servertoepassingen maken met AppMaster.
AppMaster's no-code generation platform laat ontwikkelaars het gRPC protocol gebruiken om verzoeken te doen tussen backend microservices architectuur. Volgend jaar breiden we de gRPC ondersteuning uit door API's op te nemen voor zowel gRPC Web als gRPC Mobile applicaties.
Conclusie
Hoewel gRPC diensten verschillende voordelen hebben die ze aantrekkelijk maken voor bedrijven en ontwikkelaars, hangt de beslissing om gRPC diensten te gebruiken boven andere zoals REST of SOAP uiteindelijk af van uw toepassing. Terwijl sommige software grote voordelen heeft met gRPC, zijn andere misschien beter geschikt voor de alternatieven. U moet de nadelen en voordelen van gRPC services begrijpen en beslissen of het voor u werkt.
