Orbit bruger GraphQL til dataforespørgsler

Brian Kejlberg

Brian Kejlberg

Developer hos Orbit Online A/S

Udgivet

23 October 2023

En kort introduktion til GraphQL

GraphQL er en teknologi udviklet af Facebook (nu Meta), som behandler mange millioner dataforespørgsler i sekundet. Det er med andre ord et teknisk sprog designet specifikt til dataforespørgsler.

Sproget er bygget omkring den matematiske betegnelse for en graf - det vil sige prikker eller punkter forbundet med kanter. Derfor navnet GraphQL (Graph Query Language).

For os betyder det, at vi kan garantere vores kunder og deres slutbrugere, at Orbit er bygget på en grundigt testet og pålidelig teknologi, der løbende udvikles og er skalerbar til vores brugeres behov.

Dette er vores måde at fremtidssikre Orbit - og dermed også din virksomhed.

Den tekniske forklaring

GraphQL giver serveren mulighed for kun at håndtere én API. Serveren trækker således på de gode egenskaber fra en fælles API, hvor klienterne selv anmoder om versionering samt de datafelter, der skal bruges til versionen. Desuden standardiserer GraphQL måden, klienten indlæser data på - uanset enhedstype og datakompleksitet. Dette betyder, at vi undgår at udvikle variationer i den type data, som klienten indlæser.

Alt i alt vil det resultere i en enklere arbejdsgang for udviklerne - og stabil databehandling for systemerne.

Specifikationskravene til integration med Orbit

Ganske enkelt kan kravene til en succesfuld integration med Orbit reduceres til følgende simple formel:

HTTPS + XML.

Dette kan kun gøres, fordi vi har en standardiseret API til vores import. Her har vi valgt at bruge XML-formatet med det tilhørende XSD-skema. Det dækker en anerkendt og udbredt teknologi, der tilbyder en rigdom af funktionelle værktøjer, der kan hjælpe med at bygge korrekte XML-data.

Hvordan vores dataimport fungerer i praksis

Måden det fungerer på er, at du indsender XML-data via HTTPS og en API-nøgle. Derefter vil du straks få at vide, om data stemmer overens med XSD-skemaet, hvilket kan have to udfald:

• Hvis valideringen godkendes, vil dataene blive sat i kø til import.
• Hvis valideringen mislykkes, vil du få et svar tilbage med XSD-valideringsfejlmeddelelser.

Ud over dette har vi udviklet en webgrænseflade, hvor du har mulighed for at validere den enkelte enhedstype, der understøttes af Orbit.

I importkøen struktureres data fra XML-filen i en række pr. enhed, så de passer til XSD-skemaet. Derefter importeres en enhed ad gangen via opkald til vores GraphQL-server.

Når data skal ud af Orbit

Orbit-data kan nemt og hurtigt eksporteres i de fleste filtyper - inklusive Word / InDesign / PowerPoint / Excel / XML / CSV. Desuden har vi en direkte integration med PowerBI, hvilket kan gøre det endnu nemmere at visualisere og dele forretningsdata med resten af organisationen. Vi arbejder konstant på at gøre vores API mere tilgængelig. I øjeblikket lægger vi stor indsats i at gøre dataeksport til eksterne digitale platforme lige så glat og strømlinet som vores import - og vi er ikke langt fra målet.

Du kan selv tage hånd om alle integrationer

Som udgangspunkt vil du være i stand til selv at starte integrationen af dine data i Orbit.

Dette skyldes, at vi stiller detaljeret API-dokumentation til rådighed for hver type enhed, som vores import understøtter. Vi opfordrer dig også til at bruge vores webgrænseflade til at validere dine data, før du starter den egentlige import.

Vi giver præcis vejledning og assistance. Blandt andet kan du finde hjælp på vores introduktionsside til API-dokumentationen, som fortæller dig, hvordan vores API'er fungerer, og hvordan du laver forespørgsler mod dem.

På denne måde har vi gjort det let for vores kunder at tage hånd om integrationerne selv. Og selvfølgelig er vi altid klar til at hjælpe dig, hvis der skulle opstå udfordringer.

Men hvorfor ikke bare bruge en eksisterende standard teknologi?

Hvis du arbejder med eksisterende standardteknologier, såsom SOAP+XML, RESTful JSON eller et tilpasset format, er der typisk to tilgange til at lave dine dataudtræk, én type API pr. platform og en fælles API pr. type information.

Lad os tage et nærmere kig på hver af dem.

Én type API pr. platform

Den første tilgang er at lave en API pr. type information pr. platform (f.eks., web light, web heavy, mobile, import, etc.). Dette betyder, at hver platform får præcis den information, den har brug for - hverken mere eller mindre.

Denne løsning præsenterer flere udfordringer. Først og fremmest er det en kompleks proces for udviklere at holde styr på så mange versioner af "den samme API".

For det andet vil der være en høj risiko for, at der opstår fejl.

For det tredje vil selv simple API-ændringer typisk være meget besværlige og tidskrævende, fordi du konstant skal teste, om tingene fungerer ordentligt på alle platforme.

En fælles API pr. type information

Den anden tilgang er at skabe en fælles API pr. type information, som alle platforme deler. Denne løsning betyder, at du som udvikler kun skal holde én API opdateret pr. information, hvilket forenkler arbejdet markant.

På den anden side vil en fælles API-løsning typisk resultere i for meget data, der flyder frem og tilbage mellem klient og server. Dette vil sætte serverne og netværket under unødvendigt højt pres i forbindelse med hver forespørgsel, da de skal håndtere en masse data og trafik, der alligevel ikke skal bruges.

Mine forbehold ved valg af teknologi til Orbit

I forbindelse med udviklingen af Orbit skabte de to nævnte teknologier en række bekymringer. Især havde jeg følgende forbehold:

• Unødvendig kompleksitet i samarbejdet mellem flere udviklere.
• For mange workarounds i forhold til API-versionering.
• Begrænsninger vedrørende databehandling på forskellige enheder.