Sådan faldt Paypal pladask for Graphql

Illustration: Wikimedia Commons
Betalingstjenesten startede i det stille med graf-søgesproget. I dag er det den måde, man bygger brugerflader på i firmaet.

Det startede med et simpelt kasseapparat – af den virtuelle slags, på en webside. Men så gik tingene slag i slag for betalingstjenesten Paypal.

Det handler om graf-søgesproget Graphql, der har vist sig at være lidt af en universalløsning til brugerflader, skriver Shruti Kapoor, som er udvikler hos Paypal, i et blogindlæg.

I dag bruges Graphql af flere produktionsapps på tværs af betalingstjenesten og det er standarden at bruge sproget, når der skal bygges nye apps med brugerflader, og mange er på vej over på platformen.

Graphql har sin oprindelse hos Facebook, og sproget har fået meget omtale i de senere år.

Med det browserbaserede værktøj Graphiql kan en forespørgsel med Graphql opbygges ved at sætte krydser ved felterne. I højre panel ses resultatet af søgningen. Illustration: Version2

Det er kun få år siden, at Graphql blev sluppet ud i offentligheden 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, Airbnb og altså også Paypal.

Læs også: Graphql kan samle alle data-forespørgsler under én hat

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.

Paypal bruger sproget til at bygge nye brugerfladebaserede apps. Firmaet er i gang med at flytte mange eksisterende apps til Graphql. Det bruges til at give en ens oplevelse på tværs af alle firmaets produkter.

Graphql bygger også bro mellem frontend og backend, da sproget kan virke som et slags orkestreringslag for api’er, noget som andre også tidligere har fremhævet.

Hverken for meget eller for lidt data

Graphql har løst en lang række problemer for Paypal. Nogle af dem lå lige til højrebenet for søgesproget. Det drejede sig om situationer, hvor api’er henter for mange data, hvilket netop var det problem, Graphql oprindeligt var sat i verden for at løse. Med Graphql kan de ønskede data specificeres i selve kaldet, så der ikke spildes med båndbredde og unødvendige forespørgsler i datakilderne. Det er især anvendeligt i brugerflader.

Et andet problem er opslag af værdier, der er nødvendige for at slå andre værdier op, såsom /getProfileById/{id}, hvor man måske først skal kalde getUser{username} for at få den ønskede id-parameter.

Det behøver man ikke med Graphql.

En tredje problem fandtes i forbindelse med versionerede api’er. Når en ny version af et api blev udsendt, skulle klienterne opgradere for eksempelvis at få nye datasæt. Det er ikke noget problem med Graphql, hvor datastrukturen kan opdateres efter forgodtbefindende.

En bonus med Graphql var også, at det giver frihed til at benytte de fleste programmeringssprog, når der skal integreres med kundernes systemer. Det kræver nu også mindre grad af forståelse af problemfeltet, når der skal integreres.

Med sproget er det også muligt at måle, i hvor høj grad de enkelte datafelter anvendes, så de, der ikke anvendes længere kan udfases på en fornuftig måde. Paypals REST-api’er blev også mere ensartede, da alle hold nu bruger det samme schema (datastruktur).

Hurtigere produktopdateringer

En erfaring, Paypal gjorde sig med den brede indføring af Graphql, var ikke overraskende, at de forskellige hold oplevede samme udfordringer. Hjulet blev opfundet på ny, og derfor besluttede firmaet at indføre standarder for anvendelsen samt værktøjer. Interne api’er har navnekonventioner, typer, standarder for header-felter og fejlhåndtering.

Der stilles også frontend- og backend-skabeloner til rådighed for holdene, samt undervisning og et internt miljø ved hjælp af chat-tjenesten Slack.

Graphql har givet firmaet en række fordele. Det handler om udviklerproduktivitet, som øges med værktøjer, samt adgang til hele schema’et, og backend- og frontend-folk, der udformer schema’et i fællesskab, hvilket er med til at nedbryde siloer.

Det har ganske simpelt ført til hurtigere produktopdateringer, skriver Shruti Kapoor:

»Vi var i stand til at slippe af med en masse rørlægning, der gjorde det sværere at levere funktionsopdateringer og beholde funktionsparitet. Før måtte vi udsende et SDK (udviklingspakke) til alle sprog, som vores kunder arbejdede med. Nu kan vi levere et enkelt Graphql-endpoint, som kunderne kan integrere med, uanset hvilket sprog de bruger.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (0)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Log ind eller Opret konto for at kommentere