Adio, GraphQL: de ce după 6 ani entuziasmul s-a stins

Vă aduceți aminte când GraphQL părea un glonț de argint pentru API-uri? Un singur endpoint, fără overfetching, clientul decide ce vrea. Ei bine, după 6 ani de exploatare intensivă, unii dezvoltatori încep să observe că glonțul nu e chiar atât de argintiu.

Ce a mers prost?

Autorul, după jumătate de deceniu cu GraphQL, evidențiază câteva probleme cheie:

• Complexitatea cache-ului. În REST, cache-ul la nivel HTTP e de bază. În GraphQL, fiecare cerere e unică, iar cache-ul trebuie construit manual pe client. E o durere.
• Performanța. Problema N+1 e un clasic. DataLoader ajută, dar nu întotdeauna. Când ai zeci de cereri imbricate, baza de date începe să plângă.
• Complexitatea uneltelor. GraphQL necesită generare de tipuri, scheme, rezolvere. Cu cât echipa e mai mare, cu atât haosul e mai mare. Și încearcă să explici unui începător ce e __typename și de ce e necesar.
• Suprasolicitare pentru proiecte simple. Dacă ai un CRUD cu trei entități, GraphQL e ca un tun pentru vrăbii. REST face treaba mai repede și mai simplu.

REST — nu e perfect, dar e predictibil

Autorul nu cheamă pe nimeni să migreze urgent înapoi la REST. Dar observă că pentru majoritatea serviciilor interne și proiectelor mici, REST rămâne o alegere mai pragmatică. GraphQL e bun pentru aplicații complexe, orientate pe client, cu o mulțime de clienți eterogeni (mobil, web, IoT). Dar dacă ai un singur client web — de ce să complici?

Comentariul studioului METABYTE: Alegerea între REST și GraphQL nu e un război religios, ci o decizie inginerească. Dacă proiectul tău seamănă cu un set Lego (multe piese mici) — GraphQL poate fi potrivit. Dar dacă vrei doar să construiești rapid un API pentru o aplicație tipică — REST cu OpenAPI e adesea ciocanul care nu caută cuie acolo unde nu sunt.