Graphql – Verander en verbeter die manier waarop toepassings kommunikeer

Dit sal nie lank duur voordat die volgende generasie kripto sal koop en hul effektetrustbalans in die fortnite lobby tussen speletjies. Dit sal moontlik gemaak word deur baie tegnologiese vooruitgang.

Die een wat ons vandag bespreek, is die manier waarop data oorgedra word (gelees, opgedateer, bygevoeg/verwyder) tussen toepassings en die maatskappye wat hulle besit. Toepassingsprogrammeringskoppelvlakke (API) is die argitektuur wat hierdie datakommunikasie definieer en soos hierdie standaarde ontwikkel het, het verwerkingsvereistes en databergingsvereistes minder moeilik geword.

Die leier in die pakket in terme van "liggewig" hulpbrongebruik is GraphQL, 'n oopbron-datanavraag en manipulasietaal. Die grondslag van sy ekosisteem is sy spesifikasie en 'n versameling gereedskap wat daaromheen geskep is.

Dit is nie nuut nie – tyd beweeg vinnig. Facebook het dit in 2012 ontwikkel en dit net intern gebruik vir mobiele toepassingsontwikkeling. In 2015 was dit 'oopbron' en vandag word dit deur die GraphQL-stigting versorg (https://graphql.org/foundation/) wat toesig hou oor die verdere ontwikkeling daarvan.

So hoekom skryf ek nou daaroor? 'n Tipiese padkaart na 'n tegnologiese aanvaarding sal die volgende toepassings volg 1) stokperdjies/persoonlike projekte, 2) implementering oor veelvuldige tale, 3) implementering oor begin-ups en klein maatskappye, 4) mediumgrootte maatskappye en gebruik in produkontwikkeling, 5 ) groot korporasies en tegnologiereuse.

GraphQL het vlak 5 bereik. Tans word dit deur GitHub, Pinterest, Shopify, Microsoft gebruik om maar 'n paar te noem en mees onlangs, vanaf Maart 2022, Salesforce.

Op soek na 'n manier om data meer doeltreffend van Salesforce af te haal, het ek op hul GraphQL-dokumentasie afgekom en begin lees en na maniere kyk om dit te implementeer.

Hoe verskil dit van 'n tradisionele REST API?

• Een van die groot voordele is dat jy met GraphQL navraag kan doen en net daardie spesifieke data teruggestuur het. As jy net twee velde wil hê wat verband hou met 'n spesifieke kliëntvoorval, dan is dit wat jy kry. 'n Tradisionele REST API sal AL die velde wat met die voorval verband hou, aan jou terugbesorg. Dit kan 100+ velde wees. Nou moet jy iets doen met al daardie data waarmee jy nie wou begin nie. Hierna word verwys as data oorhaal (onderhaal is ook 'n probleem).
• Bogenoemde maak GraphQL vinniger as ander API-metodologie wanneer data teruggestuur word.
• GraphQL is 'n sterk getikte taal wat onder andere beteken dat kodefoute opgetel word voordat die program loop en nie tydens dit nie.
• 'n Groot stel gereedskap is rondom GraphQL gebou, wat dit baie ontwikkelaarvriendelik gemaak het.
• GraphQL het 'n enkele eindpunt in teenstelling met REST API wat veelvuldige eindpunte het. Dit beteken dat al jou data in 'n enkele versoek gehaal kan word.

Twee kante van die muntstuk: versoeker (kliënt) en verskaffer (GraphQL-gasheer)

Ek het tot dusver na GraphQL gekyk vanuit die data "versoek" perspektief. Waar 'n maatskappy soos Salesforce of Microsoft 'n GraphQL API opgestel het wat jy kan gebruik om navraag te doen en data te manipuleer (lees, opdateer, voeg by).

As 'n voorbeeld, as ons data van Salesforce-verwante kliëntvoorvalle by 'n kliëntportaal wil insluit, sal die doeltreffendste manier om dit te doen wees om die presiese data waarna ons soek deur 'n GraphQL-navraag van die portaal na die Salesforce GraphQL-bediener aan te vra. Jy sal presies die data kry wat jy wil hê, geen onder- of oorhaal nie en gevolglik sal geen bykomende verwerking of databerging nodig wees nie.

Die ander kant van die munt is die organisasie wat die GraphQL-argitektuur opstel sodat jou kliënte 'n doeltreffende metode kan hê om toegang te verkry tot die data wat hulle ook wil hê.

Met die bou van die GraphQL API skep 'n organisasie 'n model wat al hul stelsels in een model integreer. Dit verenig hierdie stelsels en sodra dit klaar is, verwyder dit die kompleksiteit van die onderliggende stelsel. Sodra die werk voltooi is, word die navrae van die data naatloos deur die API.

Wanneer ek toepassings of verskaffers vergelyk, kyk ek na watter funksies hulle my bied om my data van hulle terug te kry. Ek wil nie hulle e-pos hoef te stuur of op rigiede voorafbepaalde verslae staat te maak nie. Ek wil op 'n buigsame, tydige wyse by my data kan 'inprop' deur dit navraag te doen. As dit neerkom op twee toepassings/verskaffers en hulle is soortgelyk op ander vergelykingspunte, en een bied óf 'n REST API óf 'n GraphQL API, sal ek beslis die een met die API kies.