Graphql – Schimbarea și îmbunătățirea modului în care aplicațiile comunică

Nu va trece mult până când următoarea generație va cumpăra cripto și își va verifica echilibrul de încredere în unitate lobby fortnite între jocuri. Acest lucru va fi posibil prin multe progrese tehnologice.

Cel despre care discutăm astăzi este modul în care datele sunt transferate (citite, actualizate, adăugate/eliminate) între aplicații și companiile care le dețin. Interfețele de programare a aplicațiilor (API) reprezintă arhitectura care definește această comunicare de date și, pe măsură ce aceste standarde s-au dezvoltat, cerințele de procesare și de stocare a datelor au devenit mai puțin dificile.

Liderul în pachet în ceea ce privește „utilizarea „ușoară” a resurselor este GraphQL, un limbaj de interogare și manipulare a datelor open-source. Fundamentul ecosistemului său este specificația și o colecție de instrumente care au fost create în jurul său.

Nu este nou – timpul se mișcă repede. Facebook l-a dezvoltat în 2012 și l-a folosit doar intern pentru dezvoltarea de aplicații mobile. În 2015 a fost „open sourced”, iar astăzi este îngrijit de Fundația GraphQL (https://graphql.org/foundation/) care supraveghează dezvoltarea sa ulterioară.

Deci de ce scriu despre asta acum? O foaie de parcurs tipică către o adoptare tehnologică va urma următoarele preluări: 1) pasionați/proiecte personale, 2) implementare în mai multe limbi, 3) implementări în start-up-uri și companii mici, 4) companii mijlocii și utilizate în dezvoltarea de produse, 5 ) mari corporații și giganți ai tehnologiei.

GraphQL a atins nivelul 5. În prezent este folosit de GitHub, Pinterest, Shopify, Microsoft pentru a numi doar câteva și cel mai recent, din martie 2022, Salesforce.

Căutând o modalitate de a prelua datele mai eficient de la Salesforce, am dat peste documentația lor GraphQL și am început să citesc și să caut modalități de implementare.

Cum diferă de un API REST tradițional?

• Unul dintre avantajele majore este că, cu GraphQL, puteți interoga și ați returnat doar acele date specifice. Dacă doriți doar două câmpuri legate de un anumit incident client, atunci acesta este ceea ce obțineți. Un API REST tradițional îți va returna TOATE câmpurile asociate incidentului. Ar putea fi peste 100 de câmpuri. Acum trebuie să faci ceva cu toate acele date cu care nu ai vrut să începi. Aceasta este denumită date peste preluare (sub preluarea este, de asemenea, o problemă).
• Cele de mai sus fac GraphQL mai rapid decât altă metodologie API atunci când returnează date.
• GraphQL este un limbaj puternic tipizat, care, printre altele, înseamnă că erorile de cod sunt preluate înainte de rularea programului și nu în timpul acestuia.
• Un set grozav de instrumente a fost construit în jurul GraphQL, ceea ce l-a făcut foarte prietenos pentru dezvoltatori.
• GraphQL are un singur punct final, spre deosebire de API-ul REST, care are mai multe puncte finale. Aceasta înseamnă că toate datele dumneavoastră pot fi preluate într-o singură solicitare.

Două fețe ale monedei: solicitant (client) și furnizor (gazdă GraphQL)

M-am uitat la GraphQL până acum din perspectiva „cererii” de date. În cazul în care o companie, cum ar fi Salesforce sau Microsoft, a configurat un API GraphQL pe care îl puteți utiliza pentru a interoga și a manipula date (citește, actualiza, adăuga).

De exemplu, dacă dorim să includem date de la incidentele client legate de Salesforce într-un portal de client, cel mai eficient mod de a face acest lucru ar fi să solicităm datele exacte pe care le căutăm printr-o interogare GraphQL de pe portal către serverul Salesforce GraphQL. Veți obține exact datele pe care le doriți, fără preluare insuficientă sau excesivă și, prin urmare, nu va fi necesară nicio prelucrare suplimentară sau stocare a datelor.

Cealaltă față a monedei este organizația care configurează arhitectura GraphQL, astfel încât clienții tăi să aibă o metodă eficientă de a accesa și datele pe care le doresc.

În construirea API-ului GraphQL, o organizație creează un model care își integrează toate sistemele într-un singur model. Unifică aceste sisteme și, odată terminat, elimină complexitatea sistemului de bază. Odată ce munca este finalizată, interogarea datelor devine fără probleme prin API.

Când compar aplicațiile sau furnizorii, mă uit la ce funcții îmi oferă aceștia pentru a-mi recupera datele de la ei. Nu vreau să fiu nevoit să le e-mail sau să mă bazez pe rapoarte rigide predefinite. Vreau să mă pot „conecta” la datele mele interogând-o într-un mod flexibil, în timp util. Dacă se rezumă la două aplicații/furnizori și aceștia se potrivesc în mod similar pe alte puncte de comparație, iar unul oferă fie un API REST, fie un API GraphQL, cu siguranță îl voi alege pe cel cu API.