Graphql – Ndryshimi dhe përmirësimi i mënyrës së komunikimit të aplikacioneve

Nuk do të kalojë shumë kohë përpara se gjenerata e ardhshme do të blejë kripto dhe do të kontrollojë bilancin e besimit të njësisë së tyre lobi fortnite në mes të lojërave. Kjo do të mundësohet përmes shumë përparimeve teknologjike.

Ajo që po diskutojmë sot është mënyra se si transferohen të dhënat (lexohen, përditësohen, shtohen/heqen) ndërmjet aplikacioneve dhe kompanive që i zotërojnë ato. Ndërfaqet e programimit të aplikacioneve (API) janë arkitektura që përcaktojnë këtë komunikim të të dhënave dhe, me zhvillimin e këtyre standardeve, kërkesat e përpunimit dhe kërkesat për ruajtjen e të dhënave janë bërë më pak të vështira.

Udhëheqësi në paketë për sa i përket përdorimit të burimeve "të lehta" është GraphQL, një gjuhë e pyetjeve dhe manipulimit të të dhënave me burim të hapur. Themeli i ekosistemit të tij është specifikimi i tij dhe një koleksion mjetesh që janë krijuar rreth tij.

Nuk është e re - koha ecën shpejt. Facebook e zhvilloi atë në 2012 dhe e përdori vetëm brenda vendit për zhvillimin e aplikacioneve celulare. Në vitin 2015 ishte "me burim të hapur" dhe sot kujdeset për të nga Fondacioni GraphQL (https://graphql.org/foundation/) i cili mbikëqyr zhvillimin e mëtejshëm të tij.

Pra, pse po shkruaj për të tani? Një udhërrëfyes tipik drejt një adoptimi teknologjik do të ndjekë hapat e mëposhtëm: 1) hobiistët/projektet personale, 2) zbatimi në gjuhë të shumta, 3) zbatimet në ndërmarrjet fillestare dhe kompanitë e vogla, 4) kompanitë e mesme dhe të përdorura në zhvillimin e produktit, 5 ) korporatat e mëdha dhe gjigantët e teknologjisë.

GraphQL ka arritur nivelin 5. Aktualisht përdoret nga GitHub, Pinterest, Shopify, Microsoft për të përmendur vetëm disa dhe më së fundi, që nga marsi 2022, Salesforce.

Duke kërkuar për një mënyrë për të marrë të dhëna në mënyrë më efikase nga Salesforce, hasa në dokumentacionin e tyre GraphQL dhe fillova të lexoj dhe të shikoj mënyra për ta zbatuar atë.

Si ndryshon nga një API tradicionale REST?

• Një nga avantazhet kryesore është se me GraphQL mund të kërkoni dhe të keni kthyer vetëm ato të dhëna specifike. Nëse dëshironi vetëm dy fusha që lidhen me një incident specifik të klientit, atëherë kjo është ajo që merrni. Një API tradicionale REST do t'ju kthente TË GJITHA fushat që lidhen me incidentin. Mund të jenë mbi 100 fusha. Tani duhet të bëni diçka me të gjitha ato të dhëna me të cilat nuk keni dashur të filloni. Kjo referohet si të dhënat gjatë marrjes (nën marrje është gjithashtu një çështje).
• Sa më sipër e bën GraphQL më të shpejtë se metodologjia tjetër API kur kthen të dhëna.
• GraphQL është një gjuhë e shtypur fort, e cila ndër të tjera do të thotë që gabimet e kodit merren përpara se programi të ekzekutohet dhe jo gjatë tij.
• Një grup i madh mjetesh janë ndërtuar rreth GraphQL, gjë që e ka bërë atë shumë miqësore me zhvilluesit.
• GraphQL ka një pikë të vetme fundore në krahasim me REST API e cila ka pika të shumta fundore. Kjo do të thotë që të gjitha të dhënat tuaja mund të merren në një kërkesë të vetme.

Dy anët e medaljes: kërkuesi (klienti) dhe ofruesi (host i GraphQL)

Unë e kam shikuar GraphQL deri më tani nga këndvështrimi i "kërkesës" së të dhënave. Kur një kompani si Salesforce ose Microsoft kanë krijuar një API GraphQL që mund ta përdorni për të kërkuar dhe manipuluar të dhënat (lexoni, përditësoni, shtoni).

Si shembull, nëse do të donim të përfshinim të dhëna nga incidentet e klientëve të lidhur me Salesforce në një portal klienti, mënyra më efikase për ta bërë këtë do të ishte të kërkojmë të dhënat e sakta që kërkojmë përmes një pyetjeje GraphQL nga portali në serverin Salesforce GraphQL. Ju do të merrni saktësisht të dhënat që dëshironi, pa tërheqje nën ose mbi dhe si rezultat nuk do të kërkohet asnjë përpunim ose ruajtje shtesë e të dhënave.

Ana tjetër e medaljes është organizata që konfiguron arkitekturën GraphQL në mënyrë që klientët tuaj të kenë një metodë efikase për të hyrë në të dhënat që dëshirojnë gjithashtu.

Në ndërtimin e GraphQL API një organizatë po krijon një model që integron të gjitha sistemet e tyre në një model. Ai unifikon këto sisteme dhe pasi të kryhet heq kompleksitetin e sistemit themelor. Pasi të përfundojë puna, kërkimi i të dhënave bëhet i qetë përmes API-së.

Kur krahasoj aplikacionet ose ofruesit, shikoj se çfarë funksionesh më ofrojnë për të marrë të dhënat e mia prej tyre. Nuk dua t'i dërgoj me email ose të mbështetem në raporte të ngurtë të paracaktuara. Unë dua të jem në gjendje të "fus në prizë" të dhënat e mia duke i kërkuar ato në një mënyrë fleksibël dhe në kohë. Nëse bëhet fjalë për dy aplikacione / ofrues dhe ato përputhen në mënyrë të ngjashme në pika të tjera krahasimi, dhe njëri ofron ose një API REST ose një API GraphQL, unë me siguri do të zgjedh atë me API.