GraphQL are un cost. Aveți aplicațiile care îl justifică?

O echipă care construiește o singură aplicație web ar trebui să stabilească cine are nevoie să aleagă forma răspunsurilor primite prin API. Dacă aceiași oameni controlează interfața și serverul, un API REST sau RPC cu tipuri definite este un punct de plecare rezonabil. GraphQL merită ales când există un motiv concret: aplicații independente, cu cerințe diferite, pentru care coordonarea unor răspunsuri fixe devine costisitoare.

Aceasta este o regulă de decizie, nu o interdicție. Numărul aplicațiilor oferă doar un indiciu despre dificultatea coordonării. O singură aplicație complexă poate justifica GraphQL; mai multe aplicații cu nevoi asemănătoare s-ar putea să nu-l justifice. Contează câtă libertate le trebuie celor care consumă datele și cine întreține mecanismele care fac această libertate sigură.

De la nemulțumire la estimarea muncii

În articolul din 24 mai 2024, Matt Bessey a criticat GraphQL din perspectiva securității, performanței și mentenanței, pornind de la propria experiență. Relatarea arată dificultățile întâlnite de un inginer; nu măsoară toate implementările GraphQL. Este utilă fiindcă pune munca de operare alături de atracția de a cere exact câmpurile necesare unui ecran.

La începutul unui proiect, notați aplicațiile care consumă deja datele. Treceți cine răspunde de ele și când apar versiunile noi. O aplicație mobilă lansată separat are alte constrângeri decât un site publicat odată cu serverul. Un partener extern adaugă alte condiții. Includeți aplicațiile viitoare în estimare numai dacă există un plan credibil pentru ele.

Descrieți apoi o schimbare probabilă. Ca exercițiu de proiectare, presupuneți că ecranul unui client cere totalurile facturilor, iar cel de asistență cere ultimele evenimente de livrare. Dacă aceeași echipă poate adăuga două răspunsuri potrivite în aceeași versiune, coordonarea poate costa puțin. Dacă echipe independente așteaptă repetat asemenea schimbări, alegerea datelor de către fiecare aplicație devine mai valoroasă. GraphQL trebuie să compenseze acest cost al așteptării.

Libertatea de interogare cere limite explicite

Numărul adreselor unui API spune puțin despre munca serverului. În GraphQL, două cereri trimise la aceeași adresă pot solicita cantități foarte diferite de date. Ghidul actual de securitate GraphQL discută paginarea, limitarea adâncimii și evaluarea complexității interogărilor. Acestea sunt recomandări actuale de proiectare, nu dovezi despre limitele aplicate de un anumit server în 2024.

Estimarea trebuie să includă alegerea limitelor și analiza cererilor legitime care le depășesc. Dacă o limită blochează cel mai important ecran pentru clienți, alegerea privește și produsul, nu doar securitatea. Cineva trebuie să poată explica compromisul și să răspundă de el.

Și accesul la date cere un plan. Dacă încărcați o listă, apoi citiți separat înregistrările asociate fiecărui element, numărul operațiilor în baza de date poate crește mult. Aceeași greșeală este posibilă în REST. Avantajul practic al unui răspuns bine delimitat este că echipa are mai puține combinații de verificat. Niciunul dintre protocoale nu asigură automat un plan eficient de acces la date.

Permisiunile țin de regulile afacerii

Un utilizator care poate vedea numele unui client nu are neapărat dreptul să vadă și datele de plată. Recomandările GraphQL despre autorizare plasează verificarea permisiunilor în logica afacerii. Astfel, aceeași regulă poate fi aplicată oriunde se ajunge la datele respective.

Proiectul propus ar trebui să arate cum rămâne protejat un câmp sensibil atunci când este accesat pe căi diferite. O verificare într-un singur ecran sau într-o singură funcție de rezolvare nu ajunge dacă există alt drum către aceeași înregistrare. Și REST cere permisiuni pentru obiecte și câmpuri. Alegerea lui nu elimină această obligație. Pentru un produs mic, controlat de aceeași echipă, avantajul este suprafața mai restrânsă a răspunsurilor care trebuie analizate.

Aici pot induce în eroare estimările. O schemă se poate genera repede. Demonstrarea faptului că utilizatorii primesc numai datele permise cere muncă separată. Cereți să apară explicit în estimare, înainte să considerați că un explorator API funcțional înseamnă un proiect terminat.

Ce se schimbă când aprobați doar anumite operații

Pentru aplicațiile proprii, o listă de operații aprobate poate restrânge cererile acceptate în producție. Ghidul despre documente de încredere explică mecanismul. Stocarea interogărilor doar pentru a reduce traficul este altceva decât respingerea oricărei operații necunoscute.

O listă impusă de server face ca interfața operațională să semene cu operații RPC numite: serverul acceptă o formă cunoscută a cererii, cu parametri. Rămân însă schema GraphQL, compunerea datelor și instrumentele existente. Ar fi inexact să le declarăm identice. Comparația ajută la o decizie practică: dacă producția acceptă numai un catalog fix, ce avantaje GraphQL justifică în continuare mentenanța?

Experiența echipei poate fi un răspuns solid. Refolosirea unui sistem GraphQL bine administrat poate costa mai puțin decât introducerea unui al doilea stil de API. Restrângerea cererilor poate fi și o alegere deliberată de securitate.

O arhitectură potrivită celor care folosesc datele

Argumentul cel mai puternic pentru GraphQL este independența echipelor: aplicațiile evoluează în ritmuri diferite și combină aceleași date în moduri utile. Disciplina schemei și mentenanța competentă pot justifica investiția. Riscul alegerii implicite este să plătiți această muncă înainte să existe nevoia de independență.

Într-o aplicație existentă, schimbarea protocolului cere o justificare separată. Migrarea poate consuma timp fără să îmbunătățească o sarcină a clientului. Identificați întâi problema reală: permisiuni, acces la baza de date, coordonare sau instrumente. S-ar putea să fie suficientă repararea ei.

Pentru un proiect software la comandă, cereți o comparație scrisă pornind de la ecrane și responsabili reali. Alegeți contractul cel mai restrâns care le servește și notați ce schimbare viitoare ar justifica reanalizarea lui. Echipa va putea explica decizia și după plecarea arhitectului inițial.