Graphql kan samle alle data-forespørgsler under én hat

Foto : furo_felix, bigstock

Graphql kan samle alle data-forespørgsler under én hat

Gradvist og distribueret kan REST-kald og datakilder forenes med søgesproget Graphql, med mange fordele til følge, mener konsulent.
Brødtekst

VERSION2: Søgesproget Graphql, som har sin oprindelse hos Facebook, har fået meget omtale i de senere år. Det er kun få år siden, at Graphql blev offentliggjort efter at have været brugt og udviklet internt hos Facebook siden 2012. Siden har sproget fundet vej til en række store it-selskaber, som Netflix, Paypal og Airbnb.

Et af sprogets fordele er hastighed.

I Graphql kan brugeren specificere de felter, der er interesse i, og definere, hvordan data skal struktureres. Resterende datafelter kan ignoreres, hvilket giver hurtigere svartider og mindre pres på serveren.

Det har været vigtigt hos Netflix, der i selskabets marketingafdeling har bygget Graphql ind som et lag mellem klienten og REST-api'er.

Et eksempel på Graphql kan ses i en nylig Version2-artikel.

På den virtuelle udviklerkonference Gotopia, der blev afholdt i februar, fortalte Uri Goldshtein om hvordan søgesproget kan forene en virksomheds datakilder.

Han kommer fra konsulentgruppen The Guild, som beskæftiger sig med Graphql og open source-teknologi.

For en god ordens skyld skal det nævnes, at denne artikel også bygger på Uri Goldshteins video-foredrag med samme overskrift på Graphql Galaxy Conference, på grund af problemer med lyd- og billed-transmissionen i journalistens ende.

Gradvist og distribueret

Uri Goldshtein fremlægger i sit indlæg, hvordan konsulenterne fra The Guild introducerer Graphql i store kodebaser. Nogle fremgangsmåder virker bedre end andre. Overskriften er 'gradvist og distribueret.'

Graphql kan beskrive data og deres indbyrdes forbindelser, og en mulighed for at skabe forespørgsler, udmønter Uri Goldshtein.

En klient kan spørge til en server eller flere tjenester, og en Graphql-motor kan orkestrere de forskellige kald.

Klienten stiller et spørgsmål, og får et svar, som er udformet på den måde, som klienten vil have det.

Læs også: Tech-kæmper omfavner GraphQL: Det har ændret, hvordan vi tænker data

Fordelene er som nævnt bedre netværksydelse, et 'schema' for data-grafen, som forklarer de data, man ønsker at konsumere, orkestrering og automatisering, og eksplicitte relationer mellem udviklerhold og systemets tjenester.

Schemas er datadefinitioner, som det eksempelvis kendes fra SQL og relationsdatabaser.

Graphql oven på REST og SQL

I dag hentes data fra mobil- eller webklienter ofte via et REST-kald, og så tilrettes data i klienten, så det passer med brugerfladen. Her giver Graphql et alternativ med de tidligere nævnte fordele, og det er et populært valg.

Blandt andet fordi det er nemmere at tilføje et lille bibliotek til klienten end at sætte en ny server op, fortæller Uri Goldshtein.

På et senere tidspunkt kan Graphql flyttes til serversiden, når behovet opstår. Når det er sket, benytter serversidens Graphql-motor de samme REST-api’er som i scenariet med klienterne.

I de fleste virksomheder er det ikke så nemt at ændre tjenesterne bag REST-kaldene til at snakke Graphql. Det skyldes, at der som oftest er andre forhold, der er vigtigere at tage fat i, og fordi tjenesterne bag kaldene måske ejes af andre interne eller eksterne hold, og kan kræve en årelang proces for at ændres.

Men måske har virksomheden allerede disse kalds data-schemas, i form af GRPC, Openapi, SQL, eller man kan skabe hjemmelavede Json-schemaer ud fra kaldene.

Det er baggrunden for open source-produktet Graphql Mesh, som The Guild står bag. Her kan disse schemaer konverteres til noget, som en Graphql-motor kan anvende.

Sammensyning af datamodeller

Ideen er altså at tage den eksisterende information og konvertere den til noget som Graphql kan forstå. Så kan man skabe forespørgsler med Graphql til de underliggende systemer, der ikke behøver at forstå sproget.

Læs også: Netflix udsender Graphql-framework som open source

Det kan udmøntes i det begreb, der hedder ‘schema stiching’ - sammensyning af datamodeller. Fremgangsmåden skaber ét schema, som udgør en Graphql-gateway til de underliggende datakilder.

Uri Goldshtein betoner, at det ikke nødvendigvis betyder, at man skal binde sig til bestemte produkter eller frameworks.

Resultatet er som nævnt et centralt punkt, hvorfra alle systemets datakilder kan forespørges med ét enkelt Graphql-udtryk. I tilgift kan man udover en central gateway, som måske også kan blive et ‘single point of failure’, få indgange til de underliggende kilder ved hjælp af Graphql, også kaldet et ‘mesh’, en net-struktur af datakilder.

Register i stedet for én gateway

Vi ønsker noget som er distribueret og kan indføres gradvist, men også noget, hvor forespørgslerne kan udmøntes i et graf-udtryk, mener Uri Goldshtein.

Det kan løses med et ‘registry’, et register over de forskellige tjenester og deres schemas. The Guild har et open source-produkt, Graphql Hive, på vej til dette formål.

De stor-forenede forespørgsler betyder også, at man kan opsætte regler og best practices, der er gældende for hele virksomheden på tværs af udviklerhold. Dette kan også gøres uden nødvendigvis at centralisere via én fælles gateway.

Uri Goldshtein slutter med at betone - endnu en gang - at fremgangsmåden skal være ‘gradvis og distribueret’. Ellers kan man man købe sig ind i løsninger, der længere nede af vejen viser sig ikke at være hensigtsmæssige, lyder rådet.

Prøv DataTech gratis

DataTech giver dig ny viden, cases og erfaringer med at lykkes med AI og data science i praksis. Få 3 ugers gratis og uforpligtende prøveabonnement

Klik her