Frontend-ul tău are nevoie de date de la server. Cum le ceri? REST e vechiul standard, GraphQL a fost tendința anilor trecuți, iar tRPC a cucerit echipele TypeScript în ultimii ani. Fiecare e instrumentul potrivit pentru un context; iată cum alegi.
REST: standardul care încă domină
REST expune resurse prin URL-uri: GET /api/users, POST /api/orders. E simplu, previzibil, cacheabil, documentat de toată lumea. E alegerea corectă când: ai o aplicație publică expusă și la alți consumatori, vrei cache la nivel de CDN sau transmiți date între servicii diferite. Lumea întreagă știe să consume REST – asta e o superputere.
GraphQL: flexibilitate cu prețul complexității
GraphQL îți dă un singur endpoint și întrebări precise: „dă-mi numele și emailul utilizatorilor cu comenzile lor”. Elimină over-fetching și under-fetching. Dar cere disciplină: schemă mentinută, resolvere organizate, caching complicat. E excelent pentru aplicații cu multe entități și clienturi multiple; e exagerat pentru 90% din proiectele mici.
tRPC: tipuri end-to-end fără cod de transport
tRPC îți dă apeluri de proceduri cu tipuri TypeScript complet sincronizate între client și server. Fără definire de API, fără documentație manuală: tipul din funcția serverului e tipul din funcția clientului. Compilatorul îți prinde orice schimbare de semnătură. Prețul: client și server trebuie să fie în același monorepo TypeScript. E alegerea perfectă pentru aplicații interne, admin și start-up-uri full-stack.
Criteriile de decizie, pe scurt
- API public pentru lume: REST.
- Aplicație complexă, mulți consumatori, nevoi diverse: GraphQL.
- Frontend + backend TypeScript în aceeași echipă: tRPC.
- Durează 1 zi, trebuie să meargă 5 ani: REST sau tRPC, nu GraphQL.
Nu te agăța de un singur instrument
Majoritatea proiectelor bine făcute amestecă: REST pentru API-ul public, tRPC pentru frontend-ul propriu și GraphQL doar când apare nevoia reală. Alege pe nevoi, nu pe publicitate.
Alegerea arhitecturii e prima decizie de cost
API-ul din spate determină cât de repede se construiește și cât de ușor se întreține aplicația. La aplicațiile web full-stack pe care le livrez, arhitectura API-ului e stabilită după o discuție despre nevoile tale, nu după trending.