GRAPHQL- JA REST-RAJAPINTOJEN PERFORMANSSIEN VERTAILU
Kandidaatintyö Informaatioteknologian ja viestinnän tiedekunta Tarkastaja: Matti Monnonen Huhtikuu 2021
TIIVISTELMÄ
Jussi Kujanen: GraphQL- ja REST-rajapintojen performanssien vertailu Kandidaatintyö
Tampereen yliopisto Ohjelmistotekniikka Huhtikuu 2021
Tässä työssä vertaillaan kahta saman toiminnallisuuden toteuttavaa web-rajapintaa (engl. applica- tion programming interface, API). Ensimmäinen API on toteutettu noudattaen Roy Fieldingin mää- rittelemää Representational State Transfer-arkkitehtuuria (REST). Toinen rajapinta on toteutettu käyttäen Facebookin kehittämää GraphQL-querykieltä. Työssä vertaillaan rajapintojen viivettä ja palautettujen tavujen määrää kahdessa eri tehtävässä.
Työssä esitellään ensin REST-periaatteet, sekä REST-rajapinnan käyttöä ja sen heikkouksia. Työs- sä todetaan REST-rajapinnan aiheuttavan tietyissä tilanteissa käyttäjälle rasitusta viiveen ja la- tenssin osa-alueella. Tämän jälkeen esitellään GraphQL-querykielen periaatteellinen toiminta ja käyttö, sekä GraphQL-palvelimen toiminta. Osiossa tuodaan esille GraphQL:n ominaispiirre: vas- tuun siirtäminen palvelimelta asiakkaalle.
Teoriaosuuden jälkeen työssä tarkastellaan aiempia tutkimuksia, joissa REST- ja GraphQL-rajapintoja on vertailtu. Aiempien tutkimusten pohjalta havaitaan GraphQL:n suoriutuvan paremmin kuin REST- rajapinta, kun palvelimelta haetaan pieniä määriä dataa.
Tutkimusosuudessa esitellään tutkittava järjestelmä, tutkimuksessa käytetyt mittarit ja työkalut, sekä rajapinnoille suoritettavien tehtävien määritelmät. Vertailussa havaitaan GraphQL:n suoriu- tuvan paremmin kaikilla mittareilla molemmissa tapauksissa. GraphQL:n viive ensimmäisessä teh- tävässä oli noin 7.7 %, ja toisessa tehtävässä noin 2.5 % pienempi kuin REST-rajapinnan. Tavuja GraphQL palautti ensimmäisessä tehtävässä 11.7 %, ja toisessa tehtävässä 96 % vähemmän kuin REST-rajapinta.
Suurimmat vaikuttajat tämän vertailun tulosten kannalta arvioidaan olevan vertailussa käytetyn palvelimen tehottomuus sekä asiakkaan ja palvelimen pieni round-trip time (RTT). Jos palvelimel- la käytetty laskenta-aika on suuri, RTT:n merkitys korostuu. Aiemmissa tutkimuksissa tilanne on pääsääntöisesti ollut päinvastainen: palvelimet ovat olleet tehokkaampia kuin tässä vertailussa käytetty palvelin, ja aiemmissa tutkimuksissa asiakkaan ja palvelimen RTT on ollut korkeampi.
Avainsanat: GraphQL, REST, API
Tämän julkaisun alkuperäisyys on tarkastettu Turnitin OriginalityCheck -ohjelmalla.
SISÄLLYSLUETTELO
1. Johdanto . . . 1
2. Rest. . . 2
2.1 REST-rajapinta. . . 3
2.2 REST-API:n heikkoudet . . . 4
3. GraphQL . . . 6
3.1 GraphQL-query . . . 7
3.2 GraphQL-palvelin. . . 8
4. Aiemmat tutkimukset . . . 11
5. Rajapintojen vertailu . . . 13
5.1 Mittarit . . . 13
5.2 Toteutus . . . 13
5.3 Tulokset ja arviointi . . . 15
6. Yhteenveto . . . 18
Lähteet . . . 19
7. Liite: Repositoriot . . . 21
1. JOHDANTO
Web-pohjaisia palveluita on nykyään lukemattomia. Näiden palveluiden ongelmakohtina ovat yleisesti noudatetun rajapintastandardin puute ja vanhojen rajapintojen arkkitehtuu- rien soveltumattomuus nykyajan käyttökohteisiin. Web-palveluille on tärkeää valita mah- dollisimman pysyvä, laajennettava sekä toimiva web-rajapinta (engl. application program- ming interface, API).
2000-luvun aikana web-rajapintojen yleisimmäksi arkkitehtuuriksi on noussut Roy Fiel- dingin määrittelemä Representational State Transfer-arkkitehtuuri (REST) [1]. Yleisyy- destään huolimatta REST-arkkitehtuurilla suunnitellut rajapinnat eivät sovellu täydellisesti kaikkiin nykyajan käyttökohteisiin. Varsinkin mobiiliverkoille on tärkeää minimoida asiak- kaiden pyyntöjen määrää palvelimelle ja tähän REST ei sovellu. REST:ille on noussut viimeaikoina useita mahdollisia korvaajia, joista tunnetuin lienee Facebookin kehittämä querykieli: GraphQL.
Tässä kandidaatintyösdasasdasdssä vertaillaan kahta itse toteutettua, saman toiminnal- lisuuden toteuttavaa web-rajapintaa kontrolloidussa ympäristössä. Ensimmäinen web- rajapinnoista on toteutettu noudattaen REST-periaatteita, ja toinen käyttäen GraphQL:ää.
Työssä vertaillaan tehtyjen pyyntöjen viivettä sekä vastaanotetun datan määrää.
Toisessa luvussa esitellään REST:in periaatteet ja REST:in yleisiä ongelmia. Kolman- nessa luvussa tarkastellaan GraphQL:n toimintaa asiakkaan ja palvelimen kannalta. Nel- jännessä luvussa käydään läpi aiempia REST:iä ja GraphQL:ää vertailevia tutkimuksia.
Luvussa viisi esitellään vertailussa käytettävät menetelmät ja mittarit sekä esitellään tu- lokset ja päätelmät. Kuudennessa luvussa kootaan yhteen johtopäätökset ja havainnot.
2. REST
1990-luvulla Roy Fielding havaitsi Internetin skaalautuvuuden olevan riippuvainen erilai- sista rajoitteista. Fielding ryhmitteli rajoitteet kuuteen kategoriaan ja antoi niille yhteisen nimen:Web’s architectural style. Vuonna 2000 Fielding kuvaili väitöskirjassaan näitä ra- joitteita sekä antoi tälle kuvaukselle nimenRepresentational State Transfer.[2]
REST määrittelee 6 erilaista rajoitetta, joita web-pohjaisen palvelun tulisi noudattaa [1, luku 5.1]:
1. Client-Server: Palveluntarjoajan ja asiakkaan rajapintojen tulee olla toisistaan riip- pumattomia.
2. Stateless: Jokaisen pyynnön tulee olla omavarainen, eli pyynnön tulee sisältää kaik- ki oleellinen tieto, jotta se pystytään ymmärtämään oikein. Pyynnöt eivät saa hyöy- dyntää mitään palvelimelle tallennettua ’contextia’.
3. Cache: Palvelimen vastauksessa oleva data voidaan merkitä varastoitavaksi (engl.
cache). Tällöin asiakas voi hyödyntää varastoitua dataa myöhemmissä, samanlai- sissa pyynnöissä.
4. Uniform interface: Rajapintojen tulee olla yleiskäyttöisiä ja yhdenmukaisia.
5. Layered system: Komponenteilla tulee olla tieto ainoastaan niistä komponenteista, joiden kanssa komponentti itse on suorassa vuorovaikutuksessa.
6. Code-On-Demand: Asiakkaan on mahdollista laajentaa palvelun toiminnallisuutta lataamalla ja suorittamalla ohjelmistokoodia scriptien tai aplettejen muodossa.
REST määrittelee yhtenäiselle rajapinnalla (Uniform interface) myös neljä lisärajoitetta, joita web-komponenttien tulee noudattaa [2, luku 1]:
1. Identification of resources: Jokainen eriteltävä web-pohjainen konsepti on resurssi, ja resurssille voidaan määrittää uniikki tunniste.
2. Manipulation of resources through representation: Asiakkaat ovat tekemisissä re- sursseihin resurssien esitysten välityksellä, eivätkä itse resurssien kanssa. Esitys voi olla esimerkiksi JSON-esitys SQL-tietokannan rivistä.
3. Self-descriptive messages: Asiakkaan pyynnössä voidaan ilmoittaa resurssin ha- luttu tila ja palvelimen vastauksessa voidaan ilmoittaa resurssin nykyinen tila.
4. Hypermedia as the enginge of application state: Resurssin esitys pitää sisällään linkit siihen liittyviin toisiin resursseihin.
Fieldingin mukaan näiden rajoitteiden noudattaminen painottaa komponenttien vuoro- vaikutusten skaalautuvuutta, rajapintojen yleistettävyyttä sekä komponenttien itsenäistä käyttöönottoa. Rajoitteiden noudattaminen lisää myös Fieldingin mukaan välikomponent- tien käyttöä vuorovaikutusten viiveen vähentämiseksi, turvallisuuden vahvistamiseksi se- kä legacy-järjestelmien kapsuloimiseksi. [1, luku 5.5]
2.1 REST-rajapinta
Web-API, joka on suunniteltu noudattaen REST-periaatteita, on nimeltään REST-API. Jos web-palvelulla on REST-API, voidaan palvelua nimittää RESTful:iksi. [2, luku 1] Tämä ei kuitenkaan tarkoita, että kaikki REST-rajapinnat olisivat samanlaisia. Tämä johtuu siitä, että REST ei ole tarkka määritelmä. REST kertoo ainoastaan, minkälaisia rajoitteita web- pohjaisen palvelun suunnittelussa tulisi noudattaa.
REST:issä määritelty resurssien tunnistaminen (Identification of resources) tapahtuu in- ternetissä URL-osoitteiden (engl. Uniform Resource Locator) avulla. Jokaisella resurssilla tulee olla uniikki URL. Leonard Richardson mainitsee kirjassaan RESTful Web Apis, että uniikin URL:in antaminen asialle muuttaa kyseisen asian resurssiksi. [3, luku 3]
REST-APIT kommunikoivat webissä yleensä HTTP-protokollan avulla. Vaikka HTTP mää- rittelee kahdeksan eri metodia, jolla sen yli voidaan kommunikoida, niistä ylivoimaisesti käytetyimpiä REST-rajapinnoissa ovat GET, POST, PUT ja DELETE.
Näiden neljän metodin käyttötarkoitus REST-API:a käytettäessä voidaan kuvata seuraa- vasti [4, luku 4]:
• GET: Hae resurssin esitys.
• POST: Luo uusi resurssi annetun esityksen perusteella.
• PUT: Korvaa tämä resurssi uudella resurssilla, perustuen lähetettyyn esitykseen.
• DELETE: Poista tämä resurssi.
Yhtenäisen rajapinnan lisärajoite ’Manipulation of resources through representation’ mää- rittelee, että kommunikointi REST-rajapinnan kanssa tapahtuu resurssien esitysten avul- la. Kuvassa 2.1 on esitelty Insinöörinkatu-servicen URLiin: /expenses/id, tehdyn GET- pyynnön vastaus.
2 "data":{
3 "id": "3a91ddfc-fd63-4009-95f3-c1dec1bec9f4",
4 "title": "Gorgeus plastic salad",
5 "description": "Superior salad is superior",
6 "price": 83668,
7 "resolved": false,
8 "date": "2021-02-25T13:07:35.409Z",
9 "createdAt": "2021-02-25T13:07:35.409Z",
10 "updatedAt": "2021-02-25T13:07:35.409Z",
11 "payee": {
12 "id": "72333dee-99ee-4f40-adcd-080a9b8d3abf",
13 "username": "ExampleUser"
14 },
15 "tags": ["Food"]
16 }
17 }
1 Kuva 2.1.GET-pyynnön vastaus
Kuvasta nähdään, että vastaus sisältää JSON-muotoista dataa. Tämä JSON-muotoinen data on resurssin, ja tässä tapauksessa kulun, esitys. Palvelin määrittelee toteutukses- saan, minkälaisia resurssien esityksiä palvelin tarjoaa.
2.2 REST-API:n heikkoudet
Huomionarvoista on se, että kuvan 2.1 GET-pyynnössä ei määritelty, minkälainen esitys resurssista halutaan palautettavaksi. Kyseisessä tapauksessa palvelin palautti palvelimel- la määritellyn resurssin esityksen JSON:nina. Jos asiakas olisi ollut kiinnostunut ainoas- taan kentästä "title", palauttaisi palvelin silti kaikki muut kulun esitykseen liittyvät kentät.
Toisaalta jos asiakas haluaisi saada myös esimerkiksi enemmän maksajaan liittyvää tie- toa, tulisi tehdä toinen GET-pyyntö asiakasta vastavaan URL:iin. Nämä asiat korostavat yhtä REST:in ongelmista: on tyypillistä, että REST:iä noudatava API palauttaa joko liian paljon (engl. over fetching) tai liian vähän (engl. under fetching) tietoa. Jos tietoa on liian vähän, joudutaan usein tekemään lisää pyyntöjä.
Tämä on ongelma mobiiliverkoilla, sillä niiden round-trip time[5] (RTT) on usein suuri.
RTT tarkoittaa aikaa, joka kestää signaalin lähetyksestä kuittaukseen. Joakim Lundborg mainitsee vuoden 2016 Nordic APIs- konferensissa: "..if you have lot’s of round trips, you will get a slow application"[6]. Jos tiedonhakua varten täytyy tehdä useita pyyntöjä, RTT joudutaan suorittamaan useita kertoja, jolloin tiedonhakemiseen käytettävä kokonaisaika kasvaa.
Koska resurssien esitykset ovat määritelty palvelimella tarkasti, on REST-API myös huono mukautumaan uusiin tilanteisiin ja vaatimuksiin. Jos halutaan saada kuvassa 2.1 mainitut maksajan tiedot yhdellä pyynnöllä, tulee REST-API:n määrittää uusi URL tätä tilannetta varten. Jos erikoistapauksia on useita, tulee REST-API:sta nopeasti hankala ylläpitää.
Tämä on huono myös asiakkaan kannalta: asiakas joutuu etsimään itselleen sopivinta URL:ia.
REST-API:en yksi suurimmista ongelmista on se, että REST ei määrittele tarkalleen mil- lainen rajapinnan tulisi olla, sillä REST on vain kokoelma rajoitteita. Asiakas voi lähettää palvelimelle mitä tahansa dataa ja palvelin voi vastata millä tahansa datalla [7, luku 1].
Tämä on johtanut siihen, että monet APIt, jotka määrittelevät itsensä RESTful-API:ksi, toimivat todellisuudessa eri tavoin.
Vaikka on olemassa suuri määrä RESTfuliksi määriteltyjä rajapintoja, asiakkaalla ei ole takuuta siitä, miten ne tarkalleen ottaen toimivat. Vuoden 2018 analyysissa todettiin, että 500:sta REST-API:sta ainoastaan noin 0,8 % noudatti tarkasti kaikkia REST:in periaattei- ta [8]. Asiakkaan tulee tarkastella jokaista API:a omana kokonaisuutenaan.
3. GRAPHQL
GraphQL on vuonna 2012 Facebookin sisäisesti kehittämä data query -kieli, jonka Face- book luovutti open-source käyttöön vuonna 2015 [9]. GraphQL ei vaadi palvelimelta tiet- tyä ohjelmointikieltä tai tietokantaa, vaan palvelimet kartoittavat omat tarjoamansa omi- naisuudet GraphQL:n kieleen, tyyppijärjestelmään ja filosofiaan [10, luku 1].
GraphQL:n pohjimmainen idea on yhdistää ja mallintaa dataa graafinna. Tämä tapahtuu muodostamalla datalle skeemoja, jotka edustavat tiettyä asiaa tai käsitettä, kuten esimer- kiksi käyttäjää.[10, luku 1][11] Graafia on havainnollistettu kuvassa 3.1. GraphQL-palvelin mahdollistaa skeemojen, ja niissä määriteltyjen kenttien palauttamisen asiakkaalle, mutta ei ota kantaa siihen, miten palvelimen tulee nämä kentät hakea [10]. Tyypillisesti GraphQL on kerros palvelimen rajapinnassa ja GraphQL:n vastuulla on GraphQL-queryn eli pyyn- nön parsiminen. Tämän lisäksi vastuulla on myös pyyntöä vastaavien resolvereiden kut- suminen.. Skeemaa ja resolvereita tarkastellaan kappaleessa 3.2.
Payee
Expense
Payee
Expense
Tag
Kuva 3.1.Insinöörinkatu-servicen graaffi
Kuvassa User, Expense ja Tagit ovat eri skeemoja. Nuolet esittävät skeemojen yhteyk-
siä toisiinsa. Esimerkiksi kululla on maksaja ja tägejä. Tägeillä puolestaan on kuluja.
GraphQL käyttää graaffeja sisäisessä toteutuksessaan, jota tarkastellaan kappaleessa 3.2.
3.1 GraphQL-query
GraphQL tarjoaa käyttäjälle seuraavat neljä erilaista interaktiotyyppiä, joiden käyttötarkoi- tus voidaan kuvata seuraavasti:
1. Query: Hae pyynnössä määritellyt kentät. Analoginen REST-API:n GET:in kanssa.
2. Mutation: Muuta dataa halutulla tavalla. Mutaatiolla voidaan myös poistaa dataa.
3. Subscription: Ilmoita aina, kun haluttu data muuttuu.
4. Introspection: Hae palvelimen tukemat queryt.
[10, Luvut 6.2, 6.4]
Tämän työn vertailun kannalta olennaisin interaktiotyyppi on query, joka on myös yleisin käytetty interaktiotyyppi.
Tavallisesti GraphQL-palvelin tarjoaa yhden URL:in kaikkia interaktiotyyppejä varten. Tä- mä URL on tyypillisesti /graphql [7, luku 1]. Tällöin asiakkaan ei tarvitse tutkia useita URL-osoitteita löytääkseen itselleen sopivan rajapinnan, toisin kuin REST:ssä.
Kuvassa 3.2 on esimerkki Insinöörinkatu-serviceen lähetetystä querystä ja sen vastauk- sesta. Kyseissä queryssä haetaan kuluun liittyviä kenttiä. Queryssä määritetään palau- tettavaksi ainoastaan yksi kulu.
1 {
2 getExpenses( limit: 1 ) {
3 title
4 price
5 payee {
6 username
7 createdAt
8 }
9 }
10 }
1 (a)GraphQL-query
1 {
2 "data":{
3 "getExpenses":[
4 {
5 "title":"Gorgeus Plastic Salad",
6 "price":40000,
7 "payee":{
8 "username":"ExampleUser",
9 "createdAt":"2021-02-23T12:20:32.721Z"
10 }
11 }
12 ]
13 }
14 }
1
(b)Queryn vastaus
Kuva 3.2.GraphQL-query ja vastaus
Esimerkistä nähdään yksi GraphQL:n ominaispiirteistä: vastuun siirtäminen queryistä asiak- kaalle palvelimelta [10, luku 1]. Kyseissä queryssä asiakas määritteli palautettaviksi ken- tiksi otsikon, hinnan sekä maksaja-objektin käyttäjänimen ja käyttäjän luontihetken. Huo- mioinarvoista on, että asiakas päätti itse, mitä kenttiä halutaan palautettavaksi. Tämä on
laista dataa rajapinta palauttaa. Jos REST-rajapinnalla oltaisiin haluttu suorittaa queryä vastaava pyyntö, olisi se vaatinut kahden erillisen pyynnön tekemistä palvelimelle, johon palvelin olisi myös palauttanut tietoa, josta asiakas ei ole kiinnostunut.
Koska asiakas voi pyytää ainoastaan haluamansa datan, on mahdollista minimoida pa- lautettavan datan määrä. Täten kappaleessa 2.2 mainitut over- ja under fetching eivät ole ongelmana, kun käytetään GraphQL:ää. Tämä on hyödyllistä verkoille, joiden tiedonsiir- tokapasiteetti on rajallinen.
Query toimii sopimuksena palvelimen ja asiakkaan välillä. Palvelin määrittelee, minkälai- sia queryjä se tukee ja asiakas hyödyntää queryjä haluamallaan tavalla. Palvelimen tulee noudattaa asiakkaan pyyntöä, eikä palvelin voi esimerkiksi palauttaa queryssä määrit- telemättömiä kenttiä. Tällöin asiakkaalla on tae siitä, minkä tyyppistä dataa query tulee palauttamaan. Tämä poikkeaa REST-rajapinnasta, jossa asiakkaalla ei ole mitään takeita siitä, mitä rajapinta tulee palauttamaan. REST-rajapinnassa myöskään palvelimella ei ole takeita siitä, mitä asiakkaan pyyntö sisältää.
3.2 GraphQL-palvelin
GraphQL-palvelin vaatii käyttöään varten skeeman. Skeema on GraphQL:n määrittelyn mukaan kokoelma GraphQL-palvelun tyyppijärjestelmän kyvykkyyksiä (engl. capabilites) [10, luku 3.3]. Käytänössä tämä tarkoittaa, että halutulle palvelulle määritetään palvelimel- la kaikki mahdolliset kentät, sekä niiden tyypit. Skeema Insinöörinkatu-servicen kululle on esitelty kuvassa 3.3.
1 type Expense {
2 id: ID!
3 title: String!
4 description: String
5 price: Int!
6 resolved: Boolean!
7 date: Date!
8 payee: User
9 tags: [Tag]
10 }
1 Kuva 3.3.Kulun skeema
Skeemassa täytyy määrittää kenttien tarkat datatyypit, sillä GrahpQL on vahvasti tyypitet- ty kieli [10, luku 1]. Kuvan 3.3 skeemassa esimerkiksi "title"on kenttä ja String on sen da- tatyyppi. "User"viittaa toiseen palvelimella määritettyyn skeemaan. Kulu ja maksaja ovat tästä johtuen verkostuneita, kuten kuvassa 3.1 esitettiin.
Huutomerkit datatyyppien perässä tarkoittavat, että kenttä on "non-nullable"[10, luku 3.12].
Tämä tarkoittaa sitä, että kyseinen kenttä ei ikinä palauta tyhjää arvoa. Hakasulut tarkkoit-
tavat että kyseessä on "List Value", eli kyseinen kenttä palauttaa listan asioita. [10, luku 2.9.7] On hyvä huomata, että skeema rajaa asiakkaan ja palvelimen toimia: molempien osapuolten täytyy noudattaa skeeman määritelmää.
Myös querylle täytyy määrittää skeema. Queryn skeema määrittää, minkälainen queryn tulee olla ja mitä dataa query palauttaa. Esimerkki Insinöörinkatu-servicen queryn skee- masta on esitelty kuvassa 3.4.
1 extend type Query {
2 getExpenses(
3 id: ID
4 skip: Int
5 limit: Int
6 month: String
7 year: String
8 resolved: Boolean
9 ): [Expense]
10 }
1 Kuva 3.4.Queryn skeema
Kuvassa 3.4 "getExpenses"on queryn nimi. Sulkujen sisällä olevat kentät ovat mahdollisia parametrejä, jotka asiakas voi queryn mukana lähettää [12]. Rivillä 9 määritellään queryn palauttama arvo "[Expense]", eli lista kuluja.
Kun GraphQL vastaanottaa queryn, parsitaan se ensin abstraktiksi syntaksipuuksi (engl.
abstract syntax tree, AST). GraphQL-querystä muodostettu AST sisältää ylimääräisen metadatan lisäksi parsitun version querystä. [7, luku 4] Esimerkki kuvan 3.2 queryn muo- dostamasta AST:sta on esitelty kuvassa 3.5.
Query
Payee GetExpenses
Title Price
CreatedAt Username
Kuva 3.5.Queryn abstrakti syntaksipuu
Kuvassa juuri-alkiona on root Query type, joka toimii sisäänpääsyalkiona puuhun.[13]
Kun AST on muodostettu, GraphQL tarkistaa sen virheiden varalta. Tarkistuksessa tarkis- tetaan esimerkiksi kenttien olemassaolo. Tämä tapahtuu vertaamalla muodostettua puuta palvelimella määriteltyihin skeemoihin. [7, luku 4] [10, luku 5]
Validoinnin jälkeen GraphQL-palvelin kulkee AST-puun breadth-first-menetelmällä aloit- taen ylimmästä alkiosta, kutsuen jokaisen alkion resolveria. Resolverit ovat palvelimen toteuttamia funktioita, jotka palauttavat kentälle arvon [13]. Resolver funktiot ottavat vas- taan neljä argumenttia, jotka voidaan kuvata seuraavasti[14]:
1. Root: sisältää ylemmän tason resolverin tuloksen.
2. Args: kentälle annetut parametrit.
3. Context: arvo, joka annetaan kaikille resolvereille.
4. Info: arvo, joka sisältää kyseessä olevalle querylle oleellista tietoa.
Jos kentälle ei ole määritelty resolveria, GrahpQL etsii Root -argumentista kenttää, jol- la on sama nimi kuin kyseisellä AST -kentällä. [13] Kuvassa 3.5 tällainen kenttä on esi- merkiksi createdAt. Payee -kentän resolver palauttaa objektin, jolla on createdAt niminen kenttä, joten createdAt -kentän resolver voi palauttaa sen arvon root -argumentin kautta.
Kun kaikille puun alkioille on kutsuttu niitä vastaavaa resolver-funktiota, lopullinen loppu- tulos kerätään yhteen ja palautetaan asiakkaalle. Jos queryn ylimmällä tasolla olisi ollut useita queryttäviä kenttiä, palvelin ajaisi niitä vastaavat AST:in haarat rinnakkain. [13]
4. AIEMMAT TUTKIMUKSET
REST- ja GraphQL-rajapintoja on vertailtu useissa tutkimuksissa. Tutkimuksissa mitataan yleensä yksittäisiä pyyntöjä eikä oteta huomioon, että REST saattaa tarvita useamman pyynnön toteuttaakseen saman asian kuin GraphQL.
Esimerkiksi Lublinin teknillisen yliopiston julkaisemassa tutkimuksessa vertailtiin saman toiminnallisuuden toteuttavien REST- ja GraphQL-aplikaatioiden tehokkuuksia. Tutkimus totesti GraphQL:n olevan nopeampi kuin REST, jos palvelin oli suuren rasituksen alla ja queryttiin pieniä määriä dataa. Jos queryttiin suuria määriä dataa, REST-aplikaatiolla oli parempi tehokkuus. Tavallisessa käytössä ei kuitenkaan havaittu eroja. [15]
Minas Geraisin valtiollisen yliopiston tutkimuksessa seitsemän REST-rajapintaa käyttävää järjestelmää vaihdettiin käyttämään GraphQL-rajapintaa. Uusi GrahpQL-rajapinta palautti tutkimuksen mukaan 99 % vähemmän tavuja kuin aiemmat REST-rajapinnat.[16]
Saman yliopiston toisen tutkimuksen mukaan GrahpQL vaikuttaisi olevan myös helpom- min käytettävä asiakkaan näkökulmasta. Vuoden 2020 tutkimuksessa vertailtiin aikaa, joka kuluu queryn impelentoimiseen REST:illä ja GraphQL:llä. Tuloksista havaittiin, että queryjen tekeminen oli vaivattomampaa GraphQL:ää käytettäessä, varsinkin jos rajapin- nan kompleksisuus kasvaa.[17]
Hasanuddin yliopiston web-informaatiojärjestelmän rajapintoja analysoinut tutkimus to- tesi REST-rajapinnan olevan nopeampi kuin vastaava GraphQL-rajapinta, sillä REST:in nopeus on vakaa, kun taas GrahpQL mukautuu dynaamisesti palvelimen rasitukseen.
Analyysi totesi REST-rajapinnan tarvitsevan joskus enemmän pyyntöjä kuin GraphQL- rajapinta, mikä voisi tehdä web-aplikaatiosta hitaamman, kun käytetään REST-rajapintaa.
[18].
Aalto-yliopiston diplomityössä luotiin REST- ja GraphQL-rajapinnat olemassa olevalle pal- velulle, ja vertailtiin hakujen nopeutta näistä kahdesta rajapinnasta. Työssä vertailtiin myös palautetun datan kokoa ja käyttöastetta. Tuloksena havaittiin GraphQL:n suoriu- tuvan paremmin miltei kaikissa mittareissa. Ainoastaan spesifisissä tapauksissa REST- rajapinnan käyttöaste oli parempi.[19]
Yhteisenä teemana voi havaita GraphQL:n olevan nopeampi pienillä määrillä dataa, mut- ta jos queryttävän datan määrää nostetaan tai jos palvelin on suuren rasituksen alla,
tää enemmän aikaa pyydetyn datan jalostamiseen. REST-rajapintaa käytettäessä asiakas joutuu tyypillisesti suorittamaan tämän jalostamisen.
Varianssia tutkimusten tuloksiin aiheuttaa todennäköisesti myös palvelimien sisäiset to- teutukset. Koska REST- ja GraphQL-toteutukset ovat riipumattomia toisistaan, voivat nii- den tehokkuudet vaihdella. Jos esimerkiksi GraphQL:n resolverit on toteutettu huonosti tai eri tavalla kuin REST:in sisäinen toteutus, voivat erot olla suuriakin.
Suuria eroja voi aiheuttaa myös palvelimen tehokkuus. Tehokas palvelin pystyy vastaa- maan pyyntöihin nopeammin kuin tehoton palvelin. Tämä ero voi olla merkittävä, jos haet- tavan datan noutaminen on laskennallisesti työlästä.
Huomiota täytyy antaa myös queryttävälle datalle. Jos GraphQL palauttaa paljon vähem- män dataa kuin vastaava REST:ille kohdistettu query, voi GraphQL:n viive olla pienempi.
5. RAJAPINTOJEN VERTAILU
Tämän luvun alaluvuissa esitellään vertailussa käytettävät mittarit, käytettävät työkalut, sekä vertailun tulokset. Alaluvussa 5.3 esitetään myös johtopäätökset sekä kriittinen ar- viointi tulosten perusteella.
Vertailun kohteena on itse toteutettu web-palvelu: Insinöörinkatu-service. Insinöörinkatu- serviceä käytetään kulujen talletukseen ja lukemiseen. Insinöörinkatu-servicellä on myös graafinen käyttöliittymä, mutta tässä vertailussa sitä ei ole tarpeellista käyttää. Kommuni- kointi palvelimen kanssa tapahtuu lähettämällä ennalta määritettyjä pyyntöjä hallitusti.
5.1 Mittarit
Vertailuun valitut mittarit ovat datan hakemiseen vaadittava kokonaisviive sekä vastaano- tettujen tavujen määrä. Nämä mittarit valitaan siitä syystä, että ne ovat oleellisia asiak- kaalle ja palvelimelle.
Datan hakemiseen vaadittavalla kokonaisviiveellä tarkoitetaan sitä aikaa, joka kuluu halu- tun datan palauttamiseen kokonaisuudessaan. Kokonaisviive voi sisältää useita pyyntöjä.
Kokonaisaika valittiin mittariksi, sillä se on asiakkaalle käytettävyyden kannalta tärkeä.
Suuri kokonaisaika rajoittaa asiakkaan toimintaa ja suuri kokonaisaika on yksi näkyvim- mistä ongelmista asiakkaan näkökulmasta.
Vastaanotetut tavut on oleellinen mittari, sillä rajallisella kaistalla on oleellista maksimoi- da haluttujen bittien määrä datavirrasta. Jos kaistanleveys on liian pieni, pyynnön viive nousee. Tämä on oleellista varsinkin mobiiliverkoille. Siirretyllä datalla on myös aina jon- kinlainen hinta, joka koostuu esimerkiksi laitteiston kuluttamasta sähköstä. Tämä kulu on oleellisin suurille palvelimille, jotka palvelevat suuria määriä asiakkaita.
5.2 Toteutus
Pyyntöjen lähetys ja tulosten mittaaminen suoritetaan JMeter-sovelluksella. JMeter on avoimen lähdekehityksen sovellus, joka on suunniteltu testaamaan funktionaalista käy- töstä ja suorituskykyä rasituksen alla [20]. JMeter soveltuu hyvin tähän vertailuun, sillä se tarjoaa kaikki vertailuun tarvittavat ominaisuudet: pyyntöjen luonnin sekä lähetyksen ja tulosten mittaamisen sekä havainnoinnin.
ta dataa, johon REST ei tarjoa suoraa rajapintaa. Verkostoituneella datalla tässä työssä tarkoitetaan sellaista dataa, joka sisältää usean erilaisen konseptin, alkion, tai asian tie- toa. Esimerkiksi kuvassa 3.2 oleva GraphQL:n vastaus on verkostunutta dataa, sillä se si- sältää tietoja maksajasta sekä tägeistä. Toisessa tehtävässä haetaan verkostoitumatonta dataa, jossa asiakas haluaa ainoastaan pienen määrän kaikesta mahdollisesta datasta.
Rajapinnoille toteutettavat tehtävät määritellään seuraavasti:
(A) Hae ensimmäisten 500 kulujen kaikki kentät ja kulujen maksajan kaikki kentät.
(B) Hae ensimmäisten 500 maksetun kulun hinnat.
Huomioin arvoista tehtävässä A on se, että sitä ei ole mahdollista toteuttaa yhdellä pyyn- nöllä REST-rajapintaan, vaan asiakas joutuu tekemään kaksi pyyntöä: hae kaikki kulut ja hae kaikki käyttäjät. Tämä johtuu siitä, että REST ei tarjoa suoraa rajapintaa tälle haul- le. Tässä tapauksessa kokonaisviiveeksi lasketaan molempien pyyntöjen yhteenlaskettu viive ja vastaanotettujen tavujen kokonaismääräksi yhteenlasketut vastaanotetut tavut.
Tehtävässä A REST-pyynnöt palauttavat myös jonkin verran päällekkäistä dataa, sillä esi- merkiksi maksajan käyttäjänimi löytyy molemmista pyynnöistä. REST:iä käyttävän asiak- kaan vastuulle jäisi myös pyyntöjen datojen yhdistäminen. GraphQL palauttaa datan yh- dessä JSON -objektissa, jolloin datakentät ovat jo palautusvaiheessa yhdistyneitä. Asiak- kaalle koituvaa ylimääräistä datan jalostamisesta johtuvaa laskentaa ei kuitenkaan tar- kastella tässä tutkielmassa.
Tehtävässä B molemmat rajapinnat selviävät yhdellä pyynnöllä, mutta REST palauttaa runsaasti kenttiä, josta asiakas ei ole kiinnostunut. GraphQL puolestaan palauttaa ai- noastaan kentät, joita käyttäjä pyynnössä määritteli.
Jokaisen pyynnön jälkeen odotetaan1000ms palvelimen ylikuormittamisen välttämisek- si. Jos käytössä olisi tarpeeksi tehokas palvelin, ei tällaista rajoitetta tarvittaisi. Työssä käytetty palvelin, jolle kyselyt lähetetään, on verrattain tehoton, ja tulosten vääristymisen kannalta on tärkeää, että palvelimen rasitus pyritään minimoimaan.
Kyselyt toistetaan useaan kertaan ja saaduista datapisteistä lasketaan keskiarvo parem- man tuloksen saavuttamiseksi. Tuloksista lasketaan myös keskihajonta. Jokaisen pyyn- nön ensimmäiset 5 datapistettä jätetään pois laskuista, sillä ensimmäisten pyyntöjen viive poikkeaa paikoittain muista saman sarjan pyynnöistä merkittävästi.
Pyynnöt toteutetaan JMeterillä sarjassa. Toistojen määräksi valittiin 50. Tämän tulisi an- taa tarpeeksi kattava näytekokoelma tarkan tuloksen määrittämiseksi. Vertailussa käytet- tettävien rajapintojen sekä Insinöörinkatu-servicen toteutuksen Git-repositoryt annetaan tämän työn liitteenä.
Palvelin jolle pyynnöt tehdään, on käynnissä erillisellä tietokoneella, jotta pyyntöjen lähet-
täminen ja vastaanottaminen eivät vaikuttaisi suoraan toisiinsa. Palvelin ja asiakas sijait- sevat samassa paikallisessa verkossa ja palvelin on yhdistetty verkkoon Wi-Fin avulla.
Vastaanottavan palvelimen tietokanta alustetaan5000kululla sekä500käyttäjällä.
5.3 Tulokset ja arviointi
JMeterin piirtämä viiveen kuvaaja on esitelty kuvassa 5.1. Tehtävän A tulokset ovat esi- teltynä taulukossa 5.1. GraphQL:stä käytetään taulukoissa ja kuvaajissa lyhenettä GQL.
Pyyntö Viive (ms) Viiveen keskihajonta (ms) Palautetut tavut (kt)
REST GET expenses 85.85 4.80 217
REST GET users 30.30 3.19 73
REST yhteinen 116.15 - 290
GQL GET expenses 107.14 6.75 256
Taulukko 5.1.Tehtävän A tulokset
Kuten taulukosta 5.1 nähdään, yhteenlaskettu viive ja palautettujen tavujen määrä olivat REST-pyynnöillä suuremmat kuin vastaavalla GrahpQL-pyynnöllä. Viive oli GraphQL:llä noin7.7%pienempi ja vastaanotettuja tavuja oli11.7%vähemmän kuin REST-pyynnöillä yhteensä. GraphQL-pyynnöllä vastaavat arvot olivat suuremmat kuin kummallakaan yk- sittäisellä REST-pyynnöllä.
Tehtävän B tulokset ovat esiteltynä taulukossa 5.2.
Pyyntö Viive (ms) Viiveen keskihajonta (ms) Palautetut tavut (kt)
REST GET resolved 72.64 3.96 218
GQL GET resolved 70.84 4.50 8
Taulukko 5.2.Tehtävän B tulokset
Tehtävässä B viive sekä viiveen hajonnat olivat miltei identtiset: GraphQL:n viive oli noin 2.5 % pienempi. Eroa löytyy merkittävästi vastaanotetuista tavuista, joissa GraphQL pa- lautti 96 % vähemmän tavuja.
Rajapintojen välillä oli eroja viiveessä ja vastaanotetuissa tavuissa. Tulokset olivat pää- asiassa yhdenmukaisia aiempien tutkimusten kanssa, joita käsiteltiin kappaleessa 4. Ku- ten aiemissa tutkimuksissa, GraphQL pärjäsi paremmin viiveen ja vastaanotetun tavujen mittapuulla.
Erot viiveessä rajapintojen välillä olivat melko pieniä. Yhtenä syynä tähän on se, että muissa tutkimuksissa pyynnön kohteena oleva palvelin on yleensä ollut verrattain teho- kas, kuten esimerkiksi yliopiston palvelin. Jos palvelin pystyy lähettämään pyydetyn datan
Kuva 5.1.Viive ajan funktiona
nopeasti, suurin vaikuttaja viiveeseen on RTT. Toisaalta hitaalla palvelimella datan käsit- telyyn kuluvan ajan merkitys korostuu merkittävästi.
Tässä vertailussa käytettävä palvelin oli melko tehoton ja täten suuri osa pyyntöihin käy- tettävästä ajasta kului palvelimella tietokannan hakuihin. Koska REST- ja GraphQL-rajapinnan takana olevan tietokannan toteutus oli miltei sama, oli tämä hakuihin kulunut aika lähes- tulkoon vakio.
RTT oli myös todella pieni, noin1ms, sillä toteuttavat laitteet sijaitsivat samassa paikalli- sessa verkossa. Käytännössä asiakkaan käyttämä palvelin sijaitsee kuitenkin melkein ai- na etäverkossa. Täten RTT voi kasvaa mielivaltaisen suureksi. Vertailussa käytetyn pal- velimen tehottomuus ja pieni RTT näkyvät erityisesti tehtävässä A: vaikka REST joutui suorittamaan kaksi pyyntöä yhtä GraphQL-pyyntöä kohti, oli viive miltei sama.
On myös tärkeää huomata, että tässä vertailussa käytetty data on melko yksinkertaista:
kululla on vain kaksi aliskeemaa (Payee ja Tags). Osalla julkisista GraphQL-rajapinnoista näitä aliskeemoja voi olla kymmeniä tai satoja. Kuten kappaleessa 3.2 mainittiin, GraphQL käy jokaisen AST:n alkion lävitse. Täten GraphQL-queryn vaikutus viiveeseen voi olla erittäin suuri. Merkitys korostuu erityisesti hitaalla palvelimella.
Viiveen hajonta oli alle 10msluokkaa kaikissa kyselyissä. Hajonta johtui luultavasti lan- gattoman verkon satunnaisista häiriöistä.
Näkyvin ero oli vastaanotetuissa tavuissa: GraphQL palautti tehtävässä A kymmenyksen verran vähemmän tavuja ja tehtävässä B ainoastaan murto-osan REST-pyynnön tavuista.
Tehtävässä A ero johtui siitä, että molemmat REST-pyynnöt palauttivat maksajan "user-
name"ja "id"kentät, kun taas GraphQL palautti nämä kentät ainoastaan kerran.
Tehtävässä B erot vastaanotetuissa tavuissa olivat erittäin suuret. Tulos ei kuitenkaan ole yllättävä. Kuten kappaleessa 3 todettiin, asiakas voi muodostaa haluamansa kokonaisuu- den GraphQL-querystä. REST sen sijaan palautti kaiken kuluun liittyvän datan.
Vaikka GraphQL palautti prosentuaalisesti merkittävästi vähemmän dataa, ei tämä vaikut- tanut viiveeseen. Syynä tähän on, että tässä vertailussa pyynnöt palauttivat pienen mää- rän dataa (enintään 256 kt) suhteessa käytetyn verkon kaistanleveyteen. Jos kyseessä olevat datamäärät olisivat esimerkiksi megatavujen luokkaa, voisi tiedonsiirtoväylän kais- tanleveys olla rajoittava tekijä. Jos kaistanleveys rajoittaisi datansiirtoa, viive kasvaisi suh- teessa siirrettävän datan kokoon.
Tämä voi olla merkittävä tekijä esimerkiksi mobiiliverkoille, sillä niiden kaistanleveys on usein rajallinen. Tällaisissa tapauksissa GraphQL luultavasti olisi viiveeltään merkittäväs- ti nopeampi kuin REST. Tässä vertailussa kaistanleveys oli kuitenkin varsin riittävä siirtä- mään kaiken pyydetyn datan.
Myös tietokannan valinnalla on merkitystä tulosten kannalta. Tässä työssä käytetty pal- velin käytti tietokantanaan SQLite:ä. Tuotannossa käytetyt palvelut eivät yleensä käytä SQLitä, koska se soveltuu ainoastaan pienille tietokannoille, eikä tue rinnakkaisia hakuja tietokantaan.
Jos käytössä olisi esimerkiksi MySQL, joka tukee rinnakkaisia hakuja tietokantaan, GraphQL- queryn muodostaman AST -puun haarojen hakuja tietokantaan voitaisiin suorittaa rinnak- kain. Tämä voi vähentää GraphQL-pyynnön käsittelyyn vaadittavaa aikaa.
6. YHTEENVETO
Tässä työssä vertailtiin itse toteutetun web-palvelun saman toiminnallisuuden mahdollis- tavaa REST- ja GraphQL-rajapintaa. Vertailussa rajapintojen täytyi hakea tietoa kahden eri tehtävän mukaan. Ensimmäinen tehtävä valittiin siten, että REST-rajapinta ei kyennyt täyttämään sitä yhdellä pyynnöllä. Toinen tehtävä valittiin siten, että palvelin palautti yli- määräistä tietoa, jota ei vaadittu tehtävän suorittamiseen. Vertailun mittareina olivat pyyn- töjen vasteaika sekä vastaanotetut tavut. Vertailu toteutettiin avoimen lähdekehityksen sovelluksella.
Vertailun tuloksena havaittiin, että GraphQL suoriutui paremmin molemmilla mittareilla kuin vastaava REST-rajapinta. Erot olivat viiveen osalta melko pieniä molempien tehtä- vien kohdalla: alle 10%. Vastaanotettuja tavuja GraphQL:llä oli ensimmäisessä tehtäväs- sä noin 11% vähemmän kuin REST:illä ja toisessa noin 96% vähemmän.
Vertailuun vaikuttivat oleellisesti käytetyn palvelimen tehottomuus sekä lähiverkon käyttö.
Jos vertailu toistettaisiin tehokkaammalla palvelimella joka sijaitsisi ulkoverkossa, olisivat tulokset todennäköisesti erilaiset.
Jatkotutkimusten kannalta olisi mielekästä tarkastella kaistanleveyden vaikutusta rajapin- tojen toimintaan, kun pyyntöjen hakemaa datamäärää kasvatetaan. Jos rajapinnan pa- lauttaman datan määrää kasvatettaisiin siten, että kaistanleveys ei enää riitä, tulisi viive nousemaan. Koska GraphQL mahdollistaa ainoastaan halutun datan hakemisen, voisi ero REST-rajapintaan viiveen kannalta olla merkittävä. Mielekästä olisi myös tarkastel- la siirretyn datan määrän vaikutusta esimerkiksi sähkönkulutukseen. Suurilla palvelimilla pienetkin rahalliset säästöt voivat ajan mittaan muuttua erittäin merkityksellisiksi.
LÄHTEET
[1] Fielding, R.Architectural Styles and the Design of Network-based Software Archi- tectures. University of California, Irvine, 2000.URL:https://www.ics.uci.edu/
~fielding/pubs/dissertation/top.htm.
[2] Massé, M.REST API Design Rulebook. O’Reilly Media, Inc., 2011.
[3] Richardson, L. ja Amundsen, M.RESTful Web APIs. O’Reilly Media, Inc., 2013.
[4] Fielding, R. ja Reschke, J.Hypertext Transfer Protocol (HTTP1.1) Semantics and Content. 2014.URL:https://tools.ietf.org/html/rfc7231.
[5] Round Trip Time (RTT).URL:https://developer.mozilla.org/en-US/docs/
Glossary/Round_Trip_Time_(RTT)(viitattu 10. 03. 2021).
[6] Lundborg, J. ja Kristopher, S.Is GraphQL the end of RESTstyle APIs. 2016. (Viitattu 10. 03. 2021).
[7] Goetsch, K.GraphQL for Modern Commerce. O’Reilly Media, Inc., 2020.
[8] Neumann, A., Laranjeiro, N. ja Bernardino, J. An Analysis of Public REST Web Service APIs. IEEE, 2018.
[9] What is GraphQL?URL:https://foundation.graphql.org/(viitattu 10. 03. 2021).
[10] GraphQL.URL:http://spec.graphql.org/draft/#(viitattu 10. 03. 2021).
[11] Thinking in Graphs. URL: https : / / graphql . org / learn / thinking - in - graphs/#it-s-graphs-all-the-way-down(viitattu 10. 03. 2021).
[12] Queries and Mutations.URL:https://graphql.org/learn/queries/(viitattu 10. 03. 2021).
[13] Stuart, M.GraphQL Resolvers: Best Practices. 2018.URL:https://medium.com/
paypal-engineering/graphql-resolvers-best-practices-cd36fdbcef55 (viitattu 14. 02. 2021).
[14] Execution.URL:https://graphql.org/learn/execution/(viitattu 10. 03. 2021).
[15] Mateusz, M. ja Mariusz, D. Comparison of REST and GraphQL web technology performance. 2020.
[16] Gleison, B., Mombach, T. ja Valente, M. T.Migrating to GraphQL: A Practical As- sessment. IEEE, 2019.
[17] Brito, G. ja Valente, M. T. REST vs GraphQL: A Controlled Experiment. arXiv.org, 2020.
[18] Hartina, D. A., Lawi, A. ja Panggabean, B. L. E. Performance Analysis of GraphQL and RESTful in SIM LP2M of the Hasanuddin University.2018 2nd East Indonesia Conference on Computer and Information Technology (EIConCIT). 2018, s. 237–
240.
palvelu. Aalto-yliopisto. 2019.
[20] Apache JMeter.URL:https://jmeter.apache.org/(viitattu 15. 02. 2021).
7. LIITE: REPOSITORIOT
Tässä liitteessä ovat lueteltuna työssä käytetyn sovelluksen, asetusten ja scriptien sekä tulosten URL:it.
1. https://github.com/siikanen/insinoorinkatu-services 2. https://github.com/Kujanenj/BachelorsStudySettings
