GraphQL – Muuttamassa ja Parantamassa Sovellusten Viestintätapaa

Ennen pitkää aikaa seuraava sukupolvi ostaa cryptoja ja tarkistaa sijoitusrahastonsa 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.

Edelläkävijä “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 etenee seuraavien käyttöönottovaiheiden kautta: 1) harrastajat/henkilökohtaiset projektit, 2) käyttöönotto useilla kielillä, 3) käyttöönotto startup-yrityksissä ja pienyrityksissä, 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 (MSFT ) ja viimeksi, maaliskuussa 2022, Salesforcessa (CRM ).

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 suurimmista eduista on, että GraphQL:llä voit kysyä ja saada vain sen tietyn datan. Jos haluat vain kaksi kenttää, jotka liittyvät tiettyyn asiakkaan tukitapaukseen, saat vain ne. Perinteinen REST API palauttaisi sinulle KAIKKEA tietoa, joka liittyy tukitapaukseen. 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ä.

Kolikon kaksi puolta: 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 asiakkaiden tukitapauksista 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 ennalta määritellyistä raporteista. Haluan pystyä “liittymään” tietoihini ja kysymään niitä joustavasti ja oikea-aikaisesti. Jos valittavana on kaksi sovellusta tai palveluntarjoajaa, jotka ovat muilta osin samanlaisia, ja toinen tarjoaa joko REST API:n tai GraphQL API:n, valitsen varmasti sen, joka tarjoaa API:n.