De populaire client-server architectuur verdeelt communicatie in twee delen: één die alle zware taken opknapt en diensten aanbiedt, bekend als de server, en het andere dat die diensten geniet, bekend als de client.
In het algemeen client-server communicatie, stuurt de client gewoon een verzoek om middelen of diensten naar de server, en de server reageert op dat verzoek.
Voor client-server communicatie, moeten clients en servers bibliotheken hebben die het protocol kunnen begrijpen waarin ze communiceren. Een protocol is een taal of een set internetcommunicatieregels. Het zijn transportmechanismen die bepaalde richtlijnen volgen voor het transporteren van gegevens over het internet.
Het tweede belangrijkste aspect van clientcommunicatie is het berichtformaat waarop zowel de client als de server kunnen instemmen. Dit berichtformaat is gebaseerd op bepaalde schema’s, en door deze schema’s niet te volgen, zou communicatie niet plaatsvinden. Berichtformaten kunnen lijken op XML, dat zich aan een schema houdt, of een JSON-bestand, dat specifieke sleutel-waardeparen moet bevatten.
Een ander belangrijk aspect van dit type communicatie om te begrijpen is dat het gebaseerd is op een verzoek- en antwoordmechanisme, wat betekent dat de server alleen communiceert wanneer de client de communicatie initieert. Met REST en GraphQL is dit meestal unidirectioneel. Dit is een basisprobleem dat zal worden opgelost door technologieën zoals gRPC.
Waarom Is REST Tot Stand Gekomen?
In de vroege jaren ’90 was er een populaire client-server protocol genaamd SOAP die gebruik maakte van XML berichtindeling met een hardcoded schema. Het schema voor de berichtindeling was zeer rigide. Het gebrek aan vrijheid was wat leidde tot het verlaten van SOAP en het ontstaan van REST.
REST kwam tot stand door de groeiende populariteit van JavaScript, wat leidde tot de groei in populariteit van het JSON bestandsformaat. Het was gemakkelijk te begrijpen en handig. Het had gewoon enkele sleutel-waardeparen in zijn berichtindeling.
In simpele woorden is Rest een richtlijn voor het overdragen van JSON berichten over het internet met HTTP als zijn protocol (transportmechanisme). Met Rest hoeft men zich geen zorgen te maken over het maken van een schema.
Wat Is REST?
We hebben het gehad over het ontstaan van REST. Laten we nu eens dieper ingaan op zijn kern technologie. Dus laat me je vertellen dat REST staat voor Representational State Transfer. Rest is een gestandaardiseerde software architectuurstijl, een API die veel wordt gebruikt in de industrie.
Redenen voor de populariteit en wijdverbreide gebruik van REST
- REST is eenvoudig en gestandaardiseerd voor communicatie architectuur. Bij het gebruik van R, hoef je je geen zorgen te maken over het formatteren van je bericht of gegevens. Je hoeft je geen zorgen te maken over je berichtindeling elke keer, aangezien het allemaal gestandaardiseerd en industrie-gebruikt is.
- REST is schaalbaar. Als je dienst groter wordt en meer functionaliteit nodig heeft, kun je gemakkelijk je server herzien zonder je zorgen te maken over de prestaties van REST van de server, en je kunt nieuwe functies in volledige isolatie aanmaken, tenzij ze je gegevens verpesten.
- REST is stateless. Dit betekent dat elke aanvraag een stukje gegevens bevat dat door de server moet worden begrepen. De architectuur van de server zorgt ervoor dat de server de informatie van deze aanvraag herinnert, maar in de REST-architectuur wordt de sessiestatus op de clientzijde opgeslagen, waardoor de server efficiënter wordt en de server weinig werkbelasting heeft voor een fijnere werking.
- Tenslotte is Rest een hoogwaardige architectuur en ondersteunt caching.
Wanneer REST gebruiken
Stel je voor dat je een website maakt voor een restaurant. Je hebt alle menukaarten online en de voedselartikelen zijn verdeeld in drie categorieën:
- Starters
- Hoofdgerecht
- Dranken
Stel nu dat je alle dranken online wilt bekijken. In de Rest-architectuur kun je eenvoudig en consistent al je bronnen op API-eindpunten partitioneren. Uiteraard kun je meerdere authenticaties op ze gebruiken om ze veilig te maken.
In dit soort gevallen sturen we een GET-aanvraag naar de server naar een eindpunt waar we de gegevens van de drankenbron kunnen krijgen.
Evenzo kunnen we alle CRUD (Create, Read, Update, Delete) uitvoeren in de Rest API, wat het geschikt maakt voor grote projecten die geen superoverdracht van gegevens vereisen en niet in realtime hoeven te zijn.
Rest werkt het beste voor projecten waarbij efficiënte gegevensoverdracht een belangrijke factor is. Caching is een ander kenmerk van REST dat nuttig is voor standaardtoepassingen zoals maaltijdbestellingsapps, hotelbestellingsapps, blogwebsites, online forumwebsites, enz.
Beperkingen en problemen met REST
REST is geweldig, maar het heeft veel nadelen die in sommige gevallen vrij cruciaal zijn. Laten we erover praten.
- De behoefte aan bidirectionele communicatie.
Wat als de server gegevens naar de client moet sturen? De server wil communicatie initiëren. In de REST-architectuur is dit niet mogelijk. Je kunt natuurlijk wel wat trucs gebruiken, maar die zijn niet praktisch. - Stel je voor dat je een website met live scores aan het maken bent. Hoe zorg je ervoor dat de server een verzoek naar de client stuurt om de scoregegevens bij te werken? We kunnen klanten laten verzoeken sturen elke 10 seconden, maar dat is helemaal geen goede praktijk. Het zal de server overbelasten, wat kan leiden tot snelheidsproblemen.
- De REST-architectuur is puur verzoek en respons en ondersteunt geen gegevensstreaming (continue gebeurtenisverwerking).
- Het stateless-kenmerk van REST kan zowel als een zegen als een vloek worden beschouwd, omdat je de toestand van gegevens in de REST-architectuur niet kunt bepalen.
Waarom is gRPC tot stand gekomen?
Om het eerste probleem met REST aan te pakken, namelijk de noodzaak van bidirectionele communicatie, is WebSocket uitgevonden, die de server toestaat om de communicatie te initiëren, maar het probleem daarmee is dat het geen formaat heeft. Het stuurt gewoon bytes en heeft geen beperkingen.
De Websockets hadden geen problemen op zichzelf, maar het echte probleem is dat elke vorm van communicatie een protocol vereist en elke protocol een clientbibliotheek die kan communiceren met dat protocol.
Als je een Python-applicatie aan het ontwikkelen bent die werkt met de Rest-architectuur, heb je een HTTP-client nodig die met de server kan communiceren. In veel gevallen worden clientbibliotheken gemaakt door een derde partij, meestal een onafhankelijke ontwikkelaar. Het gebruik van derdenbibliotheken kan je veiligheid blootstellen en je hele applicatie is afhankelijk van een derde partij voor communicatie.
In het geval van een webapplicatie fungeert de browser als een clientbibliotheek, maar voor niet-webprojecten heb je een derdenclientbibliotheek nodig. Als je aan het denken bent om er een zelf te maken, onthou dan dat het niet zo eenvoudig is en je jezelf met het onderhouden van een andere applicatie belast.
Om enkele problemen met Rest en problemen met clientbibliotheken aan te pakken, heeft Google gRPC in 2015 uitgevonden.
Voor gRPC wordt één clientbibliotheek onderhouden door Google voor bijna alle populaire talen. Het gebruikt het HTTP 2-protocol onder de kap en protocol buffers (protobuf) als berichtformaat.
Je hoeft je geen zorgen te maken over een clientbibliotheek, aangezien Google die voor je onderhoudt en voor bijna elke programmeertaal. Een enkele, geconcentreerde clientbibliotheek is een van de grote sterke punten van gRPC.
Een ander voordeel van gRPC is het berichtformaat dat het gebruikt. Protocol buffers zijn taal-agnostisch, dus je kunt clients in Python maken en servers in Go en nog steeds communicatie kunnen onderhouden zonder enige problemen.
gRPC is in wezen één clientbibliotheek en één protocol dat op elk apparaat kan worden gebruikt.
Wat is gRPC?
gRPC maakt gebruik van protobuf voor communicatie. Het serialiseert proto-bestanden in binaire indeling en stuurt ze naar de server, en op de serverzijde worden ze gedeserialiseerd naar de oorspronkelijke indeling. Dat is hoe het werkt met protobuf.
gRPC heeft verschillende vormen van communicatie. Je kunt ze zien als functies van gRPC.
Functies van gRPC
- Eenzijdig verzoek: Het is een eenvoudige vorm van aanvraag-responscommunicatie waarbij de client een proto-aanvraag stuurt en, na het ontvangen ervan, de server wacht een tijdje om een proces uit te voeren en vervolgens een respons retourneert.
- Server streaming: Bij het maken van een enkele aanvraag, komt een stortvloed van gegevens als respons van de server. Bijvoorbeeld, bij het klikken op een video, stroomt er veel videogerelateerde gegevens vanaf de serverzijde.
- Client Streaming: Het is het tegenovergestelde van server streaming. Hier stuurt de client een grote hoeveelheid gegevens tegelijk naar de server. Bijvoorbeeld, dit gebeurt wanneer je een groot bestand deelt op het internet of een afbeelding of video uploadt naar het internet. De client stuurt voortdurend gegevens naar de serverzijde.
- Bidirectionele streaming: In deze vorm van communicatie sturen de client en de server meerdere berichten. Chatten is een uitstekend voorbeeld hiervan.
Dit zijn vier populaire functies van gRPC die het zo krachtig maken.
Wanneer gebruik je gRPC
Wat betreft de functies van gRPC, hebben we enkele gebruiksvoorbeelden gezien voor gRPC. Stel je voor dat je een chat-applicatie wilt maken. Je gaat niet de Rest API gebruiken, aangezien deze niet in staat is om snelle streaming van tweerichtingscommunicatie mogelijk te maken. Hiervoor gaan we de gRPC-stream gebruiken, die naast snelheid nog enkele andere voordelen biedt.
Ten eerste is het taalonafhankelijk gedrag ongeacht in welke programmeertaal de server of andere clients geschreven zijn. Communicatie kan nog steeds tot stand worden gebracht zolang het berichtformaat wordt geaccepteerd.
Dus met deze functie kan de Android-versie van de chat-app communiceren met de iOS-versie en vice versa.
Problemen met gRPC
Er zijn problemen met alles, inclusief gRPC.
- Beperkte browserondersteuning: gRPC gebruikt HTTP 2, dus het is moeilijk om de gRPC-service rechtstreeks vanuit de browser aan te roepen. Dit vereist soms het instellen van een proxy.
- Niet-leesbaar formaat: Zoals we allemaal weten, gebruikt gRPC een binair formaat dat niet door mensen kan worden gelezen. Het is een nadeel in sommige gevallen.
- Gebrek aan volwassenheid: gRPC werd ontwikkeld in 2015, dus het is nog steeds een beetje onvolwassen vergeleken met REST, en veel fouten en problemen moeten worden opgelost.
- Leerproblemen: Rest en GraphQL gebruiken JSON, wat eenvoudiger te leren is. De meeste mensen zullen proberen bij hen te blijven, aangezien protobuf nog steeds een nieuw en complex onderwerp is, dus het zal moeilijk zijn om gRPC-experts te vinden.
REST versus gRPC:
Nu zullen we het technische verschil tussen REST en gRPC bespreken.
Berichtindeling:
De berichtindeling die door REST wordt gebruikt, is meestal JSON (soms XML-indeling), wat een leesbare vorm is en gemakkelijker te hanteren. Je hoeft je geen zorgen te maken over het schema in Rest. Aan de andere kant gebruikt gRPC een protocol buffer om gegevens te serialiseren. De gecomprimeerde vorm is lichter en sneller mee te nemen. Het is in binaire indeling, dus het serialiseert en deserialiseert gegevens om deze te verzenden.
HTTP 1.1 vs. HTTP 2:
De Rest API gebruikt meestal HTTP 1.1 als zijn protocol, terwijl gRPC HTTP 2 als zijn protocol onder de motorkap gebruikt. De Rest API kan nog steeds HTTP 2 gebruiken, maar is nog steeds beperkt vanwege het request-response mechanisme. gRPC gebruikt HTTP 2 en maakt voordeel uit van HTTP 2-ondersteuning voor zowel client-response als bidirectionele communicatie. Dit is een ander aspect dat gRPC-prestaties beter maakt dan REST. Het kan unidirectionele aanvragen zoals HTTP 1.1 en bidirectionele aanvragen tegelijkertijd zoals HTTP 2 beheren.
Latentie:
gRPC’s lage latentie en hoge snelheid in communicatie maken het nuttig voor het verbinden met systemen die bestaan uit een lichtgewicht microservices-architectuur, wat de efficiëntie van berichtoverdracht verhoogt. In de meeste gevallen van het netwerk heeft REST een latentie van 25 ms, terwijl gRPC-latentie veel minder is dan REST.
Payloadlimiet:
Rest heeft een maximale payloadlimiet van 45MB bij het verzenden van uitgaande berichten, terwijl gRPC geen limiet heeft, wat betekent dat je uitgaande bericht zo zwaar kan zijn als je wilt.
Beveiliging:
Wat betreft beveiliging zal Rest achterblijven omdat het HTTP 1.1 en het JSON-formaat gebruikt, wat gemakkelijk te decoderen en te openen is. Aan de andere kant gebruikt gRPC HTTP 2, wat veel veiliger is, en gebruikt het protobuf, wat in binaire indeling is en moeilijk te decoderen is.
Snelheid:
Hier wint gRPC wederom, omdat het 10x sneller is dan Rest, en dit is om dezelfde reden, het gebruik van HTTP 2 als protocol en protobuf als berichtindeling.
De functie voor code-generatie
Rest biedt geen ingebouwde code-generatiefuncties, wat betekent dat de ontwikkelaar derde-partijtoepassingen nodig heeft om API-code te produceren, terwijl gRPC native code-generatiefuncties heeft vanwege zijn protobuf-compiler, die compatibel is met verschillende programmeertalen. Dit is nog een voordeel, met name voor microservices-architecturen.
Memphis REST Gateway
Om berichtproductie mogelijk te maken via HTTP-oproepen voor verschillende gebruiksgevallen en gemak van gebruik, heeft Memphis een HTTP-gateway toegevoegd om REST-gebaseerde aanvragen ( =berichten) te ontvangen en die berichten te produceren naar de vereiste station.
Algemene gebruiksgevallen die profiteren van de REST Gateway zijn:
- Directe productie van gebeurtenissen vanuit een frontend
- Verbinding maken met Debezium met behulp van HTTP-server
- ArgoCD webhooks
- PostHog-integratie
- Ontvang gegevens van Fivetran/Rivery/Elke ETL-platform met behulp van HTTP-oproepen
Memphis REST Gateway + een JSON-schema kan een krachtige combinatie zijn om de gegevenskwaliteit te verhogen en ervoor te zorgen dat er gezonde communicatie plaatsvindt tussen toepassingen of services.
Memphis zal binnenkort ook gRPC ondersteunen.
Conclusie
Uiteindelijk wil ik zeggen dat REST nog steeds de meest gebruikte en populaire architectuur is, en het is onmogelijk om op te geven. REST heeft veel nadelen, zoals gebrek aan gegevensstreaming, geen bidirectionele communicatie, trage snelheid, enz., maar het is het beste voor standaardtoepassingen die we dagelijks zien.
Aan de andere kant biedt gRPC, ondanks dat het jong en moeilijk te leren is, veel dingen zoals hoge gegevensstreaming aan zowel de client- als serverzijde, goede bidirectionele gegevensstreaming, is snel en compact, en maakt gebruik van HTTP 2. Vanwege zijn snelle prestaties is gRPC het best geschikt voor toepassingen met een hoog werkdruk, zoals videostreaming, muziekstreaming, online gaming, bestand delen en chattoepassingen.