GraphQL – Muuttamassa ja Parantamassa Sovellusten Viestintätapaa

Ennen pitkää aikaa seuraava sukupolvi ostaa cryptoja ja tarkistaa yksikköluottonsa saldon Fortnite-lobbysta pelien välillä. Tämä mahdollistetaan useiden teknologisten edistysten kautta.

Yksi näistä edistysaskelista on tietojen siirto (lukeminen, päivittäminen, lisääminen/poistaminen) sovellusten ja niiden omistajien välillä. Sovellusohjelmointirajapinnat (API) määrittelevät tämän tietoliikenteen arkkitehtuurin, ja kun nämä standardit ovat kehittyneet, prosessointivaatimukset ja tietovarastointivaatimukset ovat muuttuneet vähemmän raskassoutuiseksi.

Johtaja pakassa “kevyen” resurssikäytön suhteen on GraphQL, avoimen lähdekoodin tietokysely- ja manipulointikieli. Sen ekosysteemin perusta on sen määrittely ja työkalujen kokoelma, joka 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 jatkokehittämistä.

Miksi kirjoitan siitä nyt? Tyypillinen tiekartta teknologisen omaksumisen suhteen seuraa seuraavia otteita: 1) harrastajat/henkilökohtaiset projektit, 2) käyttöönotto useilla kielillä, 3) käyttöönotto aloilla ja pienillä yrityksillä, 4) keskisuurilla yrityksillä ja tuotekehityksessä, 5) suurilla yrityksillä ja teknologiajäteillä.

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

Etsiessäni tapaa hakea tietoja tehokkaammin Salesforcen avulla törmäsin heidän GraphQL-dokumentaatioonsa ja aloin lukea ja tutkia tapoja toteuttaa sitä.

Miten se eroaa perinteisestä REST API:sta?

• Yksi suurista etuoikeuksista on, että GraphQL:llä voit kysyä ja saada vain sen tietyn datan. Jos haluat vain kaksi kenttää, jotka liittyvät tiettyyn asiakastapaamiseen, saat vain ne. Perinteinen REST API palauttaisi sinulle KAIKKEA tietoa, joka liittyy tapaamiseen. Se voi olla 100+ kenttää. Nyt sinun on tehtävä jotain kaiken tuon datan kanssa, jota et halunnut alun perinkään. Tätä kutsutaan data over fetchingiksi (under fetching on myös ongelma).
• Edellä mainittu tekee GraphQL:stä nopeamman kuin muut API-menetelmät datan palauttamisessa.
• GraphQL on vahvasti tyypitetty kieli, joka tarkoittaa, että koodivirheet havaitaan ennen ohjelman suorittamista, ei sen aikana.
• Hyvä joukko työkaluja on kehitetty GraphQL:n ympärille, mikä on tehnyt siitä kehittäjien kannalta erittäin ystävällisen.
• GraphQL:llä on yksi päätepiste, kun taas REST API:lla on useita päätepisteitä. Tämä tarkoittaa, että kaikki datasi voidaan hakea yhdellä pyynnöllä.

Kahden kolikonsivun välillä: pyynnön lähettäjä (asiakas) ja tarjoaja (GraphQL-isäntä)

Olen tähän asti tarkastellut GraphQL:ia datan “pyyntö”-näkökulmasta. Esimerkiksi Salesforce tai Microsoft on asettanut GraphQL API:n, jonka kautta voit kysyä ja muokata tietoja (lue, päivitä, lisää).

Esimerkiksi, jos haluamme sisällyttää tietoja Salesforcen asiakastapaamisista asiakasportaaliimme, tehokkain tapa tehdä tämä on pyytää tarkalleen sitä tietoa, jota haluamme, GraphQL-kyselyllä portaalin ja Salesforcen GraphQL-palvelimen välillä. Saat tarkalleen sen datan, jota haluat, ilman ylitietoa tai alitietoa, ja tuloksena ei tarvita lisää prosessointia tai tietovarastointia.

Toinen puoli on organisaatio, joka asettaa GraphQL-arkkitehtuurin, jotta asiakkaat voivat käyttää tehokasta tapaa päästäkseen tietoihin, joita he haluavat.

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

Kun vertailen sovelluksia tai tarjoajia, tarkastelen, mitä toimintoja he tarjoavat minulle, jotta voin hakea datani heiltä. En halua joutua lähettämään heille sähköpostia tai riippuvaiseksi jäämään joustamattomista esitetyistä raporteista. Haluan pystyä “liittymään” tietoihini ja kysymään niitä joustavasti ja ajoituisesti. Jos se on kaksi sovellusta/tarjoajaa, jotka ovat muilta osin samanlaisia, ja toinen tarjoaa joko REST API:n tai GraphQL API:n, valitsen varmasti sen, joka tarjoaa API:n.