REST vai GraphQL? Pienempi vastaus voi vaatia raskaamman palvelimen

REST on hyvä lähtökohta, kun asiakkaat hakevat samoja resursseja samalla tavalla ja vastaukset voidaan käyttää uudelleen välimuistista. GraphQL sopii vertailuun, kun mobiili-, verkko- tai agenttisovelluksen tietotarve vaihtelee näkymittäin. GitHubin rajapintavertailussa GraphQL palauttaa asiakkaan valitsemat kentät yhdessä pyynnössä, kun vastaava REST-haku voi edellyttää useita resurssikutsuja.

Pienempi vastaus ei silti yksin ratkaise nopeutta. GraphQL-palvelin voi tehdä useita tietolähdehakuja yhden ulkoisen pyynnön sisällä, kun taas suurempi REST-vastaus voi tulla suoraan välimuistista. Valinta kannattaa tehdä sen mukaan, missä kyseisen sovelluksen viive ja kuorma syntyvät.

Vastekoko ja kutsujen määrä kertovat eri asioista

GraphQL-kyselyssä asiakas valitsee kentät ja niiden väliset suhteet. Siitä on hyötyä, jos REST-päätepiste palauttaa paljon tietoa, jota näkymä ei käytä, tai jos saman näkymän rakentaminen vaatii peräkkäisiä kutsuja. REST-vastauksesta voi tehdä kevyemmän myös rajatuilla kentillä tai näkymäkohtaisella päätepisteellä, mutta toteutukset on silloin suunniteltava ja ylläpidettävä palvelimella.

Brito, Mombach ja Valente havaitsivat migraatiotutkimuksessaan, että seitsemän asiakasohjelman palautettujen JSON-kenttien mediaani pieneni 94 prosenttia; erillisessä tutkimuskyselyjen vertailussa palautettujen tavujen mediaani pieneni 99 prosenttia. Kenttä- ja tavuluvut tulevat siis eri koeasetelmista. Seitsemän asiakkaan migraatiossa REST-kutsuja oli 29 ja niitä korvaavia GraphQL-kyselyjä 24, joten siirtomäärän suuri vähennys ei tarkoittanut yhtä suurta vähennystä kutsujen määrässä.

Tutkimuksen tavumittaus koski palautettuja JSON-dokumentteja, ei pakatun verkkoliikenteen kokoa, palvelimen CPU-käyttöä tai käyttäjän kokemaa viivettä. Erityisen suuri säästö syntyi hauissa, joissa asiakas tarvitsi esimerkiksi vain joukon alkioiden lukumäärän laajan listan sijaan. Tavusäästö riippuu siten myös siitä, mitä nykyinen rajapinta palauttaa ja mitä asiakas todella käyttää.

Välimuisti voi kääntää nopeusvertailun

Kun moni käyttäjä hakee samaa julkista sisältöä, välimuistin osuma voi poistaa tarpeen suorittaa taustahaku uudelleen. RESTin vakioitu GET-osoite on usein suoraviivainen HTTP-välimuistin avain. GraphQL:nkin vastauksia voi tallentaa, mutta kyselyn rakenne, muuttujat ja käyttäjän oikeudet voivat vaikuttaa siihen, milloin aiempi vastaus sopii seuraavalle pyytäjälle.

AWS AppSyncin välimuistidokumentaatio erottaa koko GraphQL-operaation vastauksen tallennuksen resolverien tulosten tallennuksesta: operaatiotason osuma ohittaa resolverien suorituksen, kun resolveritason osuma säästää kyseisen tiedonhaun. AppSync ottaa operaatiotason avaimessa huomioon myös kyselyn, muuttujia ja identiteettiä koskevaa tietoa. Tämä tekee selväksi, miksi pelkkä ilmoitus välimuistin käytöstä ei vielä kerro, kuinka paljon työtä pyyntö säästää.

Välimuistin hyöty pienenee, jos jokainen käyttäjä saa erilaisen vastauksen tai kyselymuodot vaihtelevat jatkuvasti. Myös vanhentuneen tiedon poistaminen on osa toteutusta: yhteisen vastauksen pitkä säilytysaika voi olla nopea mutta väärä ratkaisu usein muuttuvaan tietoon. Vertailussa tarvitaan siksi erilliset luvut koko vastauksen osumille ja tietolähteiden tai resolverien osumille.

Yksi ulkoinen pyyntö voi tehdä monta taustahakua

GraphQL:n sisäkkäiset kentät voivat aiheuttaa N+1-ongelman: palvelin hakee ensin listan ja sen jälkeen jokaisen listan alkion suhteet erillisellä tietolähdepyynnöllä. GraphQLin suorituskykyohje kuvaa eräajon keinoksi yhdistää näitä hakuja sekä sivutuksen ja kyselyn vaativuuden rajat keinoksi hallita yksittäisen operaation kuormaa. Yhden HTTP-pyynnön pieni vastaus voi siis peittää paljon sisäistä liikennettä.

Eräajo täytyy sovittaa tietolähteeseen: samanlaisten hakujen yhdistäminen auttaa vain, jos taustajärjestelmä pystyy käsittelemään yhdistetyn pyynnön tehokkaasti. Kyselyn syvyys ja palautettavien listojen koko vaikuttavat lisäksi siihen, kuinka monta kenttää ratkaistaan, vaikka asiakkaalle lopulta lähetettäisiin vähän tavuja. Kenttäkohtainen valtuutus voi tuoda lisää työtä, jos tarkistus tehdään jokaiselle alkiolle erikseen.

REST-toteutuskaan ei automaattisesti välty toistuvilta tietokantahauilta. Oleellinen vertailukohta on saman käyttäjätehtävän vaatima työ koko ketjussa: asiakkaan pyynnöt, rajapintapalvelun CPU-aika, tietolähdehaut ja mahdolliset välimuistiosumat. Ilman tätä erottelua ulkoisten kutsujen laskeminen voi antaa väärän kuvan molemmista malleista.

Valintamatriisi neljälle kuormalle

Seuraavat lähtövalinnat kuvaavat, missä kummankin mallin ominaisuudet todennäköisimmin auttavat. Ne eivät ole yleinen nopeusjärjestys: nykyiset päätepisteet, välimuisti ja taustajärjestelmät ratkaisevat lopputuloksen.

• Mobiilin vaihtelevat näkymät: GraphQL on vahva ehdokas, jos näkymät käyttävät eri kenttiä samoista olioista ja odottavat useita peräkkäisiä REST-kutsuja. Tarkista samalla, korvautuvatko verkkopyynnöt resolverien eräajoilla vai siirtyykö odotus palvelimen sisälle.
• Julkinen verkkosisältö: REST on luonteva lähtökohta, jos saman resurssin vastaus voidaan jakaa suurelle käyttäjäjoukolle välimuistista. GraphQL voi palvella samaa kuormaa hyvin, kun kyselyt ovat ennakoitavia ja koko operaation vastaukselle syntyy osumia.
• Agentin vaihtelevat tiedonhaut: GraphQL antaa asiakkaalle mahdollisuuden valita kulloinkin tarvittavat kentät ja suhteet. Jos agentti saa muodostaa kyselyt vapaasti, listojen sivutus sekä syvyyden ja kustannuksen rajat ovat tärkeä osa kapasiteetin hallintaa.
• Suuri määrä samanlaisia palvelukutsuja: Vakioitu REST-vastaus on yleensä yksinkertainen optimoida ja valvoa, jos tietotarve pysyy samana. GraphQL:n joustavuus tuo enemmän arvoa, jos asiakkaat tarvitsevat aidosti eri rakenteita tai usean tietolähteen yhdistämistä.

Mittaa valmis tehtävä, ei yksittäistä pyyntöä

Vertailuyksiköksi sopii kokonainen näkymän lataus tai agentin tiedonhaku. Toteuta sama sisältö, käyttöoikeuksien tarkistus, sivutus ja pakkaus molemmilla malleilla. Mittaa erikseen kylmä välimuisti, lämmin välimuisti ja käyttäjäkohtaiset vastaukset, joita ei voi jakaa muiden kanssa.

1. Kirjaa tehtävän aikana siirtyneet tavut pakkauksen jälkeen sekä asiakkaan HTTP-pyyntöjen määrä. Raaka JSON-koko näyttää ylimääräiset kentät, mutta se ei yksin kuvaa mobiiliyhteydellä siirtyvää määrää.
2. Mittaa asiakkaan kokema p95-viive koko tehtävälle ja erikseen rajapintapalvelun viive. Näin peräkkäisten verkkokutsujen odotus erottuu palvelimen sisäisestä ajasta.
3. Kerää rajapintapalvelun CPU-käyttö, tietokanta- ja muiden taustahakujen määrä sekä GraphQL-toteutuksessa hitaat kentät. Yksi ulkoinen kutsu on hyöty vain, jos sen vaatima sisäinen työ pysyy hyväksyttävänä.
4. Laske välimuistin osumat erikseen kokonaisille vastauksille ja taustahauille. Kirjaa myös osuman jälkeiset tietolähdekäynnit, jotta resolverin osumaa ei tulkita koko operaation osumaksi.

Pidä testissä pyyntöjen samanaikaisuus ja palautettavan tiedon määrä vertailukelpoisina. Jos GraphQL vähentää tavuja mutta kasvattaa p95-viivettä ja CPU-kuormaa, tutki ensin hitaat hakuketjut ja eräajon mahdollisuus. Jos RESTin viive syntyy peräkkäisistä verkkokutsuista, myös koottu REST-päätepiste on vertailukelpoinen vaihtoehto.

Ylläpidettävyys kuuluu samaan päätökseen

RESTin resurssit ja HTTP-menetelmät ovat monelle tiimille tuttuja, mutta asiakaskohtaiset päätepisteet voivat kasvattaa ylläpidettävien vasteiden määrää. GraphQL keskittää tietomallin tyypitettyyn skeemaan; sen kentille tarvitaan toimivat tiedonhaut, käyttöoikeudet ja muutosten hallinta. AWS:n REST- ja GraphQL-vertailu kuvaa skeeman ja tiedonhaun erot sekä sen, että malleja voidaan käyttää samassa sovelluksessa rinnakkain.

Jos välimuistista palveltava julkinen sisältö ja asiakaskohtaiset koosteet kuormittavat järjestelmää eri tavoin, niitä ei tarvitse pakottaa samaan rajapintamalliin. Ratkaiseva tulos on käyttäjätehtävän viive suhteessa siirrettyihin tavuihin, palvelimen työhön ja siihen ylläpitoon, jonka valittu rakenne vaatii.

Lue myös:

• GraphRAG vai vektori-RAG? Kysymyksen rakenne ratkaisee valinnan
• Tekoälyagentin muistia voi väärentää – neljä koodityökalua taipui
• Ollama vai ChatGPT? Yksityisyys voittaa paikallisesti, teho pilvessä