Mikä on GraphQL ja miten se eroaa REST-rajapinnoista (API)?
Perinteisesti palvelin on lähettänyt selaimelle kokonaisia sivuja ulkoasuineen ja kaikkineen. Nykyään yhä useammin palvelimelta ladataan selaimelle ensimmäisellä kyselyllä kokonainen sovellus ja tämän jälkeen selain ja palvelin välittävät toisilleen vain dataa. Eli ei kokonaisia sivuja kuten perinteisessä mallissa. Tämä mahdollistaa sulavammat käyttöliittymät ja tehostaa verkkoliikennettä koska verkon yli lähetetään vain olennainen tieto.
REST-rajapinnat ja GraphQL ovat molemmat teknologioita joilla tälläiset sovellukset keskustelevat keskenään. Loppukäyttäjän näkökulmasta molemmat ajavat täysin saman asian ja GraphQL:ää käyttävä sovellus ei välttämättä ole mitenkään REST:iä käyttävää vastinetta parempi. Lisäksi on hyvä huomata, että jatkossa molemmat pysyvät käytössä, sillä ne eivät ole täysin toisiaan korvaavia päällekkäisiä teknologioita.
REST on näistä terminä huomattavati laajempi ja kattaa useita erilaisia toteutuksia. Se ei siis ole varsinainen standardi, vaan löyhä termi tavasta tehdä asioita. Tämän takia REST-rajapinta (eli API) on usein hyvin yksilöllinen ja räätälöity. Tämän takia REST-rajapintaa käytettäessä luodaan usein riippuvuus taustajärjestelmään.
GraphQL on selvästi selkeämpi termi. Se on alunperin Facebookilta lähtöisin oleva protokolla. Vaikka nimi antaa olettaa että tällä olisi suoraan tekemistä graafitietokantojen kanssa, niin näin ei ole. GraphQL on korkeamman tason viestintäprotokolla, joka on nykyään avoin standardi. GraphQL on käytössä mm. Facebookin mobiilisovelluksissa ja sitä käytetään miljardeja kertoja päivässä.
Näiden kahden lisäksi vanhempaa ja hieman jäykempää SOAP-protokollaa käytetään yhä laajalti, mutta täysin uusia SOAP-toteutuksia näkee julkisissa verkkosovelluksissa enää harvoin. Uusi, hieman hieman erilainen vaihtoehto näille on Netflixin Falcor, mutta pääsääntöisesti valinta on tällä hetkellä GraphQL:n ja RESTin välillä.
Kumpi on parempi, GraphQL vai REST?
Kuten sanottua, kumpikaan näistä ei ole sinänsä ylivertainen. Orjallisesti parhaiden toimintatapojen mukaan tehty REST API (rajapinta) voi itseasiassa olla huonompi, sillä tämä saattaa helposti johtaa siihen että tehdään kymmenen erillistä kyselyä. GraphQL tavallaan ajaa toteutuksen siihen suuntaan että tehdään yksi isompi kysely.
Jokaisella yksittäisellä kyselyllä on aina kustannus verkkoliikenteessä. Tämä korostuu langattomissa verkoissa. Esimerkiksi kännykkäsovelluksessa tietomassa saadaan perille nopeammin ja tehokkaammin GraphQL:n mallin mukaan. Mikään ei estä tekemästä yksittäisiä isompia kyselyitä RESTin avulla, mutta yleiskäyttöiset REST rajapinnat ohjaavat toteutukset luontaisesti useampaan pieneen kyselyyn.
GraphQL:n huomattava etu on myös se, että se on selkeästi määritelty. Tämän ansiosta sovellukset jotka tukevat GraphQL:ää voivat (teoriassa) keskustella minkä tahansa GraphQL-standardia seuraavan sovelluksen kanssa. RESTin kanssa vastaavaa takuuta ei ole, sillä esimerkiksi WordPressin ja Drupalin REST-rajapinnat ovat täysin erilaisia ja niiden välillä vaihtaminen ei ole triviaali operaatio.
Edellämainittujen taustalla oleva filosofia on siis sama, mutta ne eivät ole keskenään yhteensopivia. Näin näennäisesti avoimen rajapinnan päälle rakennetaankin usein kova riippuvuus järjestelmän rajapintatoteutuksen päälle.
Toki RESTiäkin on tarkennettu ja esimerkiksi Hydra määrittelyä seuraamalla päästään sen avulla yleiskäyttöisempiin rajapintoihin. Mikäli tarkoituksena on mahdollistaa jatkossa järjestelmäriippumattomuus on GraphQL selkeämpänä standardina parempi vaihtoehto.
Lisää aiheesta:
- GraphQL frees you from CMS ecosystems
- GraphQL with PHP and the Symfony Framework
- Beyond REST: GraphQL vs. Falcor
- GraphQL Overview - Getting Started with GraphQL and Node.js
- GraphQL for Dummies
- Apollo offers data abstraction for Angular 2, React and Redux using GraphQL