Tietojen sivutus & GraphQL

[Petja Touru]

Nykyisellään jotkut rata.digitraffic.fi:n endpointit palauttavat valtavasti dataa kerrallaan. Tulevaisuudessa datamassojen kasvaessa, tämän tiedon lataaminen ja käsittely tehokkaasti on tarpeettoman työlästä; varsinkin kun osa tiedosta on luonteeltaan täysin muuttumatonta. Nykyään joudun myös yhdistelemään usean eri kyselyn palautusta oman softani päässä, jonka senkin voisi toteuttaa jo itse rajapinnassa.

Ehdotan siis että harkintaan otetaan:

• Tietojen sivutus eli pagination
• HSL:n reittioppaasta tuttu GraphQL, joka mahdollistaa ainoastaan tarpeellisen tiedon noutamisen ja juurikin siinä muodossa missä kehittäjä sen tahtoo

[Solita / Jaakko]

Terve

Kiitoksia ehdotuksesta! GraphQL vaikutti lupaavalta ja näytti integroituvan hyvin käyttämiimme teknologioihin.

Ongelma on kuitenkin kakutus. Rajapinnan suorituskyky nojaa hyvin pitkälle kakutukseen.

Tein asiasta tiketin DPO-162. Tutkitaan tarkemmin ja käydään asia LiVi:n kanssa läpi.

Yt. Jaakko / Solita

[Tomi Lapinlampi / Liikennevirasto]

GrapQL:n edut ovat olleet esillä myös Liikenne- ja Viestintäministeriön avoimen datan työryhmässä, jossa ovat mukana hallinnonalan kaikki virastot. REST alkaa teknologiana olla jo kypsässä iässä (vaikka Liikennevirastolle uudehko asia), joten meidänkin on syytä pohtia kehityksen seuraavia vaiheita. Petjalle kiitokset asian esillenostosta!

- Tomi / Liikennevirasto

[Petja Touru]

Hei!

En tunne järjestelmäarkkitehtuurianne, mutta objektit varmaan onnistuu säilömään Rediksessä tai vastaavassa varastossa.

Kun GraphQL-kysely tehdään, haettaisiin varastosta jo kakutetut objektit ja järjesteltäisiin kyselyssä pyydettyyn muotoon. CPU-hittiä ei pitäisi tulla muistissa olevien objektien osalta kovin merkittävästi.

Mikäli GraphQL toteutetaan oikein, uskon että rajapinta selviää tulevaisuudessa jopa paljon pienemmällä määrällä sisäisiä tietokantakyselyjä, sillä kehittäjä voi jättää kyselystä pois itselleen tarpeettoman datan.

Tarvittaessa voi asettaa myös IP-osoitekohtaisia rajoituksia että montako JSON key-value-pairia voidaan vuorokauden aikana palauttaa. Tämä pakottaa kehittäjät optimoimaan sovelluksensa.

-- Petja

[Teemu Sirkiä]

torstai 30. maaliskuuta 2017 20.50.28 UTC+3 Petja Touru kirjoitti:

Kun GraphQL-kysely tehdään, haettaisiin varastosta jo kakutetut objektit ja järjesteltäisiin kyselyssä pyydettyyn muotoon. CPU-hittiä ei pitäisi tulla muistissa olevien objektien osalta kovin merkittävästi.

Mikäli GraphQL toteutetaan oikein, uskon että rajapinta selviää tulevaisuudessa jopa paljon pienemmällä määrällä sisäisiä tietokantakyselyjä, sillä kehittäjä voi jättää kyselystä pois itselleen tarpeettoman datan.

Rajapinnan käyttäjän kommenttina tähän, että nykyäänhän cachesta tuleva sisältö on välimuistissa ihan sellaisenaan, jolloin ei tarvita käytännössä mitään CPU-prosessointia. Jos jokainen kyselee GraphQL:llä vähän erilaisia asioita, niin jokainen vastaus pitää kuitenkin muodostaa erikseen. Tämä syö varmasti enemmän resursseja kuin nykyinen toimintamalli. Ja tietokantakyselyiden määrää tällä on vaikea vähentää, kun cachesta tulevat vastaukset eivät tee tällä hetkellä kai yhtään tietokantakyselyä.

Jonkinlainen kyselytuki rajapintaan toki olisi mukava. Nykyinen rajapintahan on tehty pitkälle siitä ajatuksesta, että kerää kaikki tiedot ja prosessoi itse.