GraphQL – Muuttaa ja Parantaa Sovellusten Tapaan Viestittää

Se ei kestä kauan, ennen kuin seuraava sukupolvi ostaa cryptoa ja tarkistaa yksikköluottamuksensa Fortnite-lobbysta pelien välillä. Tämä mahdollistetaan useiden teknologisten edistysten kautta.

Yksi asia, josta keskustelemme tänään, on se, miten data siirretään (luetaan, päivitetään, lisätään/poistetaan) sovellusten ja niiden omistavien yritysten välillä. Sovellusohjelmointirajapinnat (API) määrittelevät tämän dataviestinnän, ja kun nämä standardit ovat kehittyneet, prosessointivaatimukset ja datavarastointivaatimukset ovat muuttuneet vähemmän raskassoutuiseksi.

Johtaja pakassa “kevyen” resurssien käytön suhteen on GraphQL, avoimen lähdekoodin datakysely- ja manipulointikieli. Sen ekosysteemin perusta on sen määritys ja joukko työkaluja, jotka on luotu sen ympärille.

Se ei ole uusi – aika liikkuu nopeasti. Facebook kehitti sen vuonna 2012 ja käytti sitä ainoastaan sisäisesti mobiilien sovellusten kehittämiseen. Vuonna 2015 se “avattiin” ja nykyään sitä ylläpitää GraphQL-säätiö (https://graphql.org/foundation/), joka valvoo sen edelleen kehittymistä.

Miksi kirjoitan siitä nyt? Tyypillinen tiekartta teknologisen omaksumisen suhteen seuraa seuraavia vaiheita: 1) harrastajat/henkilökohtaiset projektit, 2) toteutus useilla kielillä, 3) toteutukset startup-yrityksissä ja pienissä yrityksissä, 4) keskisuurten yritysten toteutukset ja käyttö tuotekehityksessä, 5) suurten yritysten ja teknologiajättien toteutukset.

GraphQL on saavuttanut tason 5. Nykyään sitä käytetään GitHubissa, Pinterestissä, Shopifyssa, Microsoftissa ja useissa muissa yrityksissä, ja viimeksi, maaliskuussa 2022, Salesforceissa.

Etsiessäni tapaa hakea dataa tehokkaammin Salesforcesta, löysin heidän GraphQL-dokumentaationsa ja aloin lukea ja tutkia tapoja toteuttaa sitä.

Miten se eroaa perinteisestä REST API:sta?

• Yksi suurista etuoista on, että GraphQL:llä voit kysyä ja saada ainoastaan sen tietyn datan. Jos haluat vain kaksi kenttää, jotka liittyvät tiettyyn asiakasasiakirjaan, niin se on mitä saat. Perinteinen REST API palauttaisi sinulle KAIKKIIN kenttiin liittyvät tiedot. Se voi olla 100+ kenttää. Nyt sinun on tehtävä jotain kaikista niistä tiedoista, joita et alun perin halunnut. Tätä kutsutaan datan ylihaun (alihaku on myös ongelma).
• Edellä mainittu tekee GraphQL:stä nopeamman kuin muut API-menetelmät datan palauttamisessa.
• GraphQL on vahvasti tyypitetty kieli, joka muun muassa tarkoittaa, että koodivirheet havaitaan ennen ohjelman suorittamista, eikä sen aikana.
• Hyvä joukko työkaluja on kehitetty GraphQL:lle, mikä on tehnyt siitä erittäin kehittäjäystävällisen.
• GraphQL:llä on yksi päätepiste, toisin kuin REST API:lla, jolla on useita päätepisteitä. Tämä tarkoittaa, että kaikki datasi voidaan hakea yhdellä pyynnöllä.

Kahden kolikon kaksi puolta: pyytäjä (asiakas) ja tarjoaja (GraphQL-isäntä)

Olen tähän asti tarkastellut GraphQL:ää datan “pyyntö”-näkökulmasta. Yritys, kuten Salesforce tai Microsoft, on asettanut GraphQL API:n, jonka kautta voit kysyä ja muuttaa dataa (luku, päivittäminen, lisääminen).

Esimerkiksi, jos haluamme sisällyttää dataa Salesforcesta asiakasasiakirjoihin asiakasportaaliin, tehokkain tapa tehdä tämä olisi pyytää tarkalleen sitä dataa, mitä haluamme, GraphQL-kyselyllä portaalin ja Salesforce GraphQL-palvelimen välillä. Saat tarkalleen sen datan, mitä haluat, ei aliohjausta eikä yliohjausta, ja seurauksena ei ole lisää prosessointia tai datavarastointia.

Toinen puoli on organisaatio, joka asettaa GraphQL-arkkitehtuurn, jotta asiakkaat voivat käyttää tehokasta menetelmää päästäkseen datansa.

Rakentaessamme GraphQL API:ta, organisaatio luo mallin, joka yhdistää kaikki järjestelmänsä yhteen. Se yhdistää nämä järjestelmät ja kun työ on valmis, datan kysely tulee vaivattomaksi API:n kautta.

Vertailemassani sovelluksia tai tarjoajia, tarkastelen, mitä toimintoja he tarjoavat minulle datani palauttamiseksi. En halua joutua sähköpostittamaan heille tai riippuvaiseksi jäädä jähmeistä ennalta määritellyistä raporteista. Haluan pystyä “liittymään” datani ja kysyä sitä joustavasti ja ajantasaisesti. Jos se tulee kahden sovelluksen/ tarjoajan välillä, ja ne ovat muilta osin samanlaisia, ja toinen tarjoaa joko REST API:n tai GraphQL API:n, valitsen varmasti sen, jolla on GraphQL API.