Er du nysgerrig efter at finde ud af, om gRPC er fremtiden? Denne artikel har til formål at forklare to arkitektoniske API-stilarter: REST og gRPC. Før vi går videre til deres forskelle, vil vi først forklare, hvad en API er, og hvorfor det er vigtigt for mikroservice-infrastrukturer.
Bagefter vil vi beskrive, hvordan RPC er basen for gRPC og overveje de kritiske aspekter af differentiering mellem gRPC og REST API'er. I betragtning af deres sammenligning vil vi endelig analysere, hvornår vi skal bruge den ene arkitektoniske type eller den anden.
API'er står for Application Programming Interfaces. Disse grænseflader fungerer som en softwareformidler, der fastlægger specifikke bestemmelser og regler for applikationer til at interagere og tale med hinanden. En API er ansvarlig for at levere et svar fra en bruger til et system, som igen sendes tilbage fra systemet til brugeren. Lyder det stadig lidt forvirrende?
Lad os forestille os, at vi booker et hotel. Vi går til hotelreservationssiden på vores bærbare computer, og den side - som er forbundet til internettet - sender data (vores anmodning) til en server. Til gengæld henter serveren dataene, fortolker dem, og når de krævede handlinger er udført, sender den et svar tilbage til os med oplysningerne på vores grænseflade. Denne proces sker takket være API'er.
En API specificerer typer af anmodninger som en applikation (webside eller mobilapp) kan sende til en anden, og fastlægger yderligere: hvordan disse anmodninger skal fremsættes; hvilken dataformater at bruge; og den praksis, som brugerne skal følge.
Denne artikel sammenligner gRPC (Google Remote Procedure Call) og REST (Representational State Transfer), fordi de repræsenterer de to mest populære arkitektoniske stilarter, når du opretter API'er.
På den ene side i en monolitisk anvendelse, alle projektets funktionaliteter er inkluderet i en enkelt enhed, mere præcist i en enkelt kodebase. På den anden side, en mikroservicearkitektur omfatter flere mindre tjenester, der kommunikerer med hinanden ved hjælp af protokoller som HTTP. Komponenttjenesterne, der er en del af mikroservicearkitekturen, kommunikerer og interagerer med hinanden via API'er. Med andre ord API'er tillade alle de tjenester, der er integreret i en mikroserviceapplikation, at forbinde og kommunikere.
Den mest anvendte arkitektoniske stil er REST API. Der er dog tre hovedmodeller, når man bygger en API: RPC (Fjernprocedureopkald), HVILE (repræsentativ statsoverførsel), og GraphQL. I denne artikel vil vi fokusere på de to første.
RPC bruger en klient-server model. Den anmodende server (med andre ord klienten) anmoder om en meddelelse, der oversættes af RPC og sendes til en anden server. Når serveren modtager anmodningen, sender den svaret tilbage til klienten. Mens serveren behandler dette opkald, blokeres klienten, og den interne meddelelse, der passerer inden for serverne, er skjult.
Endvidere giver RPC klienten mulighed for at anmode om en funktion i et bestemt format og modtage svaret i nøjagtigt det samme format. Ikke desto mindre findes metoden til at indsende et opkald med RPC API i URL'en. RPC understøtter fjernprocedureopkald både i lokale og distribuerede miljøer.
Ligesom en REST API etablerer RPC også reglerne for interaktion, og hvordan en bruger kan indsende „opkald“ (anmodninger) for at påkalde metoder, der kommunikerer og interagerer med tjenesten.
Når du bruger REST API'er, sendes svaret fra back-end-dataene til klienterne (eller brugerne) gennem JSON eller XML meddelelsesformat. Denne arkitektoniske model har tendens til at følge HTTP-protokol. Det er dog ikke ualmindeligt, at RPC-design også vælger et par ideer fra HTTP, mens RPC-modellen opretholdes. Faktisk implementeres størstedelen af moderne API'er ved at kortlægge API'erne til den samme HTTP-protokol, på trods af den anvendte model (RPC eller REST).
Når REST API'en er offentligt tilgængelig, kan hver tjeneste, der integrerer mikroserviceapplikationen, præsenteres for brugeren/klienten som en ressource som kan tilgås via følgende HTTP-kommandoer:FÅ, SLETTE, INDLÆG, og SÆTTE.
gRPC står for Google Remote Procedure Opkald og er en variant baseret på RPC-arkitekturen. Denne teknologi følger en RPC API's implementering, der bruger HTTP 2.0-protokol, men HTTP præsenteres ikke for API-udvikleren eller serveren. Derfor er der ingen grund til at bekymre sig om, hvordan RPC-koncepterne kortlægges til HTTP, hvilket reducerer kompleksiteten.
Generelt sigter gRPC mod at gøre dataoverførsler mellem mikrotjenester hurtigere. Det er baseret på fremgangsmåden til bestemmelse af en tjeneste, etablering af metoder og respektive parametre for at muliggøre fjernopkalds- og returtyper.
Desuden udtrykker den RPC API-modellen i et IDL (interface description language), som tilbyder en mere ligetil at bestemme fjernprocedurer. Som standard bruger IDL Protokolbuffere (men andre alternativer er også tilgængelige) til at beskrive servicegrænsefladen såvel som nyttelastmeddelelsernes struktur.
Nu hvor vi har et overblik over gRPC k REST, lad os se på deres vigtigste forskelle.
REST API'er følger en anmodnings-svarmodel for kommunikation Det er typisk bygget på HTTP 1.1. Desværre indebærer dette, at hvis en mikroservice modtager flere anmodninger fra flere klienter, skal modellen håndtere hver anmodning ad gangen, hvilket følgelig bremser hele systemet. Men REST API'er kan også bygges på HTTP 2, men anmodnings-svarmodellen for kommunikation forbliver den samme, hvilket forbyder REST API'er at få mest muligt ud af HTTP 2-fordelene, såsom Streaming kommunikation og tovejs understøttelse.
GrPC står ikke over for en lignende hindring. Det er bygget på HTTP 2 og følger i stedet en klient-respons-kommunikationsmodel. Disse betingelser understøtter tovejskommunikation og streamingkommunikation på grund af gRPCs evne til at modtage flere anmodninger fra flere klienter og håndtere disse anmodninger samtidigt ved konstant at streame information. Plus, gRPC kan også håndtere „unære“ interaktioner som dem, der er bygget på HTTP 1.1.
Sammenfattende er gRPC i stand til at håndtere unære interaktioner og forskellige typer streaming:
Dette aspekt er sandsynligvis en af de vigtigste REST API fordele i forhold til gRPC. På den ene side understøttes REST fuldt ud af alle browsere. På den anden side er gRPC stadig ret begrænset, når det kommer til browsersupport. Desværre kræver det GRPC-Web og et proxylag for at udføre konverteringer mellem HTTP 1.1 og HTTP 2. Derfor ender gRPC primært med at blive brugt til interne/private systemer (API-programmer inden for en bestemt organisations backend-data og applikationsfunktionalitet).
Som tidligere nævnt bruger gRPC Protokolbuffer som standard for at serialisere nyttelastdata. Denne løsning er lettere, da den muliggør et meget komprimeret format og reducerer beskedernes størrelse. Yderligere, Protobuf (eller Protocol Buffer) er binær; således serialiserer og deserialiserer den strukturerede data for at kommunikere og transmittere dem. Med andre ord kan de stærkt indtastede meddelelser automatisk konverteres fra Protobuf til klient- og serverens programmeringssprog.
I modsætning hertil er REST hovedsageligt afhængig af JSON- eller XML-formater til at sende og modtage data. Faktisk, selv om det ikke kræver nogen struktur, JSON er det mest populære format på grund af dets fleksibilitet og evne til at sende dynamiske data uden nødvendigvis at følge en streng struktur. En anden væsentlig fordel ved at bruge JSON er dens menneskelig læsbarhed niveau, som Protobuf ikke kan konkurrere med endnu.
Ikke desto mindre er JSON ikke så let eller hurtig, når det kommer til datatransmission. Årsagen til det ligger i det faktum, at når der bruges REST, skal JSON (eller andre formater) serialiseres og omdannes til det programmeringssprog, der bruges på både klient- og serversiden. Dette tilføjer et ekstra trin til processen med at overføre data, som følgelig kan skade ydeevnen og åbne en mulighed for fejl.
I modsætning til gRPC leverer REST API ikke indbyggede kodegenereringsfunktioner, hvilket betyder, at udviklere skal bruge et tredjepartsværktøj som Swagger eller Postman til at producere kode til API-anmodninger.
I modsætning hertil har gRPC native kodegenereringsfunktioner på grund af sin protoc-compiler, som er kompatibel med flere programmeringssprog. Dette er især gavnligt for mikroservicesystemer der integrerer forskellige tjenester udviklet på forskellige sprog og platforme. Alt i alt letter den indbyggede kodegenerator også oprettelse SDK (Softwareudviklingskit).
Som nævnt har det på trods af de mange fordele, gRPC tilbyder, en stor hindring: lav browserkompatibilitet. Derfor er gRPC lidt begrænset til interne/private systemer.
Tværtimod kan REST API'er have deres ulemper, som vi har diskuteret, men de forbliver mest kendte API'er til tilslutning af mikroservice-baserede systemer. Plus, REST følger Standardisering af HTTP-protokol og tilbud universel støtte, hvilket gør denne API-arkitektoniske stil til en topmulighed for udvikling af webtjenester såvel som app- og mikroservice-integrationer. Dette betyder dog ikke, at vi skal forsømme gRPC's applikationer.
gRPC arkitektonisk stil har lovende funktioner, der kan (og bør) udforskes. Det er en glimrende mulighed for at arbejde med flersprogede systemer, streaming i realtid, og for eksempel ved drift af en IoT-system der kræver let meddelelsestransmission, såsom de serialiserede Protobuf-meddelelser tillader. Desuden bør gRPC også overvejes for mobile applikationer da de ikke har brug for en browser og kan drage fordel af mindre beskeder, hvilket bevarer mobilens processorers hastighed.
Er gRPC bedre end REST API? Både gRPC og REST API har deres brugssager. gRPC udmærker sig i højtydende miljøer, understøtter tovejs streaming og bruger protokolbuffere til effektiv serialisering. REST API er enklere, mere fleksibel og bedre egnet til brug med webapplikationer eller ved interaktion med flere programmeringssprog.
REST, eller Representational State Transfer, er en populær arkitektonisk stil til opbygning af webtjenester. Det bruger standard HTTP-metoder som GET, POST, DELETE og PUT til at kommunikere mellem klienter og servere. REST er kendt for sin enkelhed og statsløshed, hvilket gør det meget velegnet til webbaserede applikationer og mikroservicearkitekturer. Det bruger typisk JSON eller XML til dataudveksling.
gRPC er en open source-ramme udviklet af Google til effektiv og højtydende kommunikation mellem mikrotjenester. Det skiller sig ud, fordi det bruger HTTP/2 til transport og protokolbuffere (Protobuf) til sit serialiseringsformat. gRPC muliggør direkte klient-serverkommunikation og streamingfunktioner, hvilket gør det hurtigere og mere effektivt til specifikke brugssager.
De vigtigste forskelle mellem gRPC k REST ligger i deres protokoller, dataformater, API-design og streamingfunktioner. gRPC bruger HTTP/2 og Protobuf, der tilbyder fordele som mindre nyttelast og tovejs streaming. Omvendt er REST afhængig af de mere traditionelle HTTP/1.1- og JSON/XML-formater med fokus på statsløs kommunikation og ressourcemanipulation gennem standard HTTP-verb.
Om gRPC er bedre end REST afhænger af dit projekts specifikke krav. gRPC tilbyder fordele i ydeevne, effektivitet og egnethed til mikrotjenester og realtidsdatastrømning. REST skinner med sin enkelhed, brede anvendelse og brugervenlighed til webbaserede tjenester. Hver har sin plads, afhængigt af din applikations behov.
gRPC er generelt hurtigere end REST på grund af dets brug af HTTP/2 og Protobuf, som muliggør mere effektiv dataserialisering og reduceret latenstid. Ydelsesfordelen afhænger dog af det specifikke anvendelsestilfælde, herunder arten af de data, der overføres, og netværksforholdene.
Ja, gRPC bruges og udvikles aktivt. Det er især foretrukket i mikroservicearkitekturer, hvor ydeevne og effektiv kommunikation er afgørende. Dens støtte til flere programmeringssprog og platforme bidrager yderligere til dens popularitet i forskellige teknologiske økosystemer.
gRPCs popularitet stammer fra dens høje ydeevne, effektivitet i kommunikation og alsidighed på tværs af sprog og platforme. Dens evne til at håndtere streamingdata og komplekse kommunikationsmønstre mellem mikrotjenester gør det til en stærk kandidat til moderne, skalerbare applikationer.
Marketing praktikant med særlig interesse for teknologi og forskning. I min fritid spiller jeg volleyball og forkæler min hund så meget som muligt.
Din daglige webudvikler, der kan lide at gemme sig i backend. Javascript og Ruby er min marmelade. Jeg fumler stadig med Docker, og mine bygninger går i stykker ret ofte.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
