Setiap kali ada project baru, pertanyaan ini hampir selalu muncul: REST atau GraphQL?
Saya sudah pakai keduanya di berbagai project — dari side project kecil sampai sistem yang dipakai ribuan user. Dan jawaban jujur saya adalah: keduanya bagus, tergantung konteks. Tapi “tergantung konteks” itu sering terasa seperti jawaban yang tidak membantu.
Jadi artikel ini akan lebih spesifik: kapan REST adalah pilihan tepat, kapan GraphQL lebih masuk akal, dan apa red flag yang menandakan kamu salah pilih.
REST API: Pondasi yang Tidak Kemana-mana
REST (Representational State Transfer) sudah ada sejak lama. Hampir semua backend developer pernah membuat REST API — dan itu bukan kebetulan.
Kelebihan REST yang Sering Diremehkan
Simplicity yang genuine. REST itu konseptual straightforward: resource punya URL, HTTP method (GET, POST, PUT, DELETE) menentukan aksi. Tidak perlu schema, tidak perlu query language khusus.
Kalau kamu onboarding developer baru ke project, mereka bisa paham REST endpoint dalam hitungan menit. Itu valuable banget di tim.
Caching yang built-in dan proven. HTTP caching bekerja dengan sangat baik untuk REST. Browser, CDN, reverse proxy — semua sudah tau cara handle GET request yang cacheable. Untuk aplikasi yang read-heavy dengan data yang tidak sering berubah, ini performance gain yang gratis.
Tooling yang mature. Postman, curl, browser dev tools, monitoring tools — semua bekerja native dengan REST. Debugging lebih mudah karena setiap request adalah URL yang bisa kamu buka langsung di browser (untuk GET).
Stateless by design. Tiap request membawa semua informasi yang dibutuhkan. Ini membuat horizontal scaling lebih mudah dan sistem lebih predictable.
Kapan REST Pilihan Tepat
- Public API yang akan dipakai third party — mereka expect REST dan lebih nyaman consume-nya
- Service sederhana dengan resource yang well-defined dan tidak banyak relasi
- Tim kecil atau project kecil di mana overhead setup GraphQL tidak worth it
- Butuh caching yang kuat (terutama untuk public data)
- Microservices yang komunikasinya sederhana
GraphQL: Power yang Datang dengan Complexity
GraphQL dikembangkan oleh Facebook (sekarang Meta) dan dirilis ke publik di 2015. Ini bukan teknologi baru lagi — sudah cukup mature dan banyak dipakai di production.
Apa yang GraphQL Selesaikan
GraphQL muncul karena ada masalah nyata dengan REST di aplikasi yang kompleks:
Over-fetching. Kamu hit endpoint /api/users/123 tapi cuma butuh nama dan email — tapi yang datang adalah seluruh objek user dengan 30+ fields. Bandwidth dan processing yang terbuang.
Under-fetching. Kamu butuh data user + list post mereka + profil picture — tapi harus hit 3 endpoint berbeda. Ini membuat N+1 requests yang memperlambat aplikasi.
Versioning yang painful. Setiap kali ada perubahan kebutuhan data di frontend, backend harus update atau membuat endpoint versi baru.
GraphQL menyelesaikan ini dengan pendekatan: client yang menentukan data apa yang dibutuhkan.
query {
user(id: "123") {
name
email
posts(limit: 5) {
title
publishedAt
}
}
}
Satu request, dapat persis data yang dibutuhkan. Tidak lebih, tidak kurang.
Kelebihan GraphQL yang Nyata
Satu endpoint, banyak query. Dibanding puluhan REST endpoint, GraphQL hanya punya satu entry point. Client query apa yang mereka butuhkan.
Strongly typed schema. GraphQL schema adalah kontrak antara backend dan frontend. Kedua tim bisa bekerja paralel berdasarkan schema yang sudah disepakati, bahkan sebelum implementasinya selesai.
Introspection. GraphQL API bisa “mendeskripsikan dirinya sendiri”. Tool seperti GraphiQL atau Apollo Studio bisa auto-generate dokumentasi dari schema.
Ideal untuk relasi data yang complex. Kalau data kamu sangat relational dan frontend butuh banyak kombinasi berbeda, GraphQL sangat elegant.
Realita GraphQL yang Harus Kamu Tau
Learning curve itu nyata. Query language, schema definition, resolver, N+1 problem (ya, GraphQL punya versinya sendiri), batching dengan DataLoader — ini semua hal yang harus kamu pelajari dan implement dengan benar.
Caching lebih susah. Karena semua request ke satu endpoint dengan HTTP POST, caching berbasis URL tidak berlaku. Kamu butuh application-level caching atau tool khusus seperti Apollo Client.
Security lebih complex. GraphQL memungkinkan query yang sangat nested dan expensive. Tanpa rate limiting dan query complexity analysis, API kamu rentan terhadap denial-of-service melalui query yang mahal.
Over-engineering risk. Saya pernah lihat project kecil yang pakai GraphQL padahal REST endpoint 5 biji sudah cukup. Hasilnya: complexity yang tidak sebanding dengan benefit.
Perbandingan Langsung: Kasus Nyata
Kasus 1: E-commerce sederhana (catalog, cart, checkout)
Rekomendasi: REST
Operasinya straightforward, resource-nya well-defined (products, orders, users), dan caching untuk catalog produk sangat valuable. REST lebih dari cukup, dan onboarding developer baru lebih mudah.
Kasus 2: Platform media sosial dengan feed kompleks
Rekomendasi: GraphQL
Feed yang personalized butuh kombinasi data yang berbeda-beda tergantung user, device, dan context. GraphQL memungkinkan setiap client ambil data yang tepat tanpa over-fetch. Ini exactly use case di mana GraphQL bersinar.
Kasus 3: Internal dashboard / admin panel
Rekomendasi: Tergantung
Kalau datanya sudah dari REST API yang ada, consume langsung dari REST. Kalau kamu build dari scratch dan datanya complex, GraphQL bisa masuk akal. Tapi untuk admin panel dengan tim kecil, REST sering lebih pragmatis.
Kasus 4: Public API untuk third-party developer
Rekomendasi: REST
Third-party developer expect REST dan sudah familiar dengan HTTP, curl, dan Postman. GraphQL punya learning curve yang bisa jadi barrier untuk adopsi.
Tren di 2026: Apa yang Berubah?
Beberapa tahun terakhir, ada beberapa perkembangan menarik:
tRPC naik daun untuk full-stack TypeScript project — ini alternatif yang menarik untuk keduanya, khususnya kalau kamu pakai Next.js.
REST + OpenAPI semakin kuat — dengan tooling seperti Swagger UI dan auto-generated client, REST modern lebih developer-friendly dari sebelumnya.
GraphQL Federation memungkinkan multiple GraphQL service digabung jadi satu schema — ini membuat GraphQL lebih viable untuk microservices architecture.
AI-generated API clients — dengan AI, generate client dari REST atau GraphQL schema jadi jauh lebih mudah, mengurangi salah satu pain point dari kedua pilihan.
Kesimpulan Pragmatis
Kalau harus ringkas jadi satu guideline:
- Mulai dengan REST. Ini default yang reasonable untuk sebagian besar project. Simpel, proven, tooling mature.
- Pertimbangkan GraphQL ketika kamu punya multiple client (web, mobile, third-party) dengan kebutuhan data yang berbeda, atau data relations yang sangat kompleks.
- Jangan over-engineer. Pilihan teknologi terbaik adalah yang bisa kamu deliver dengan cepat dan maintain dengan nyaman.
Dan ingat: kamu bisa punya keduanya. Beberapa project besar pakai REST untuk public API dan GraphQL untuk internal/mobile client. Ini bukan pilihan mutually exclusive.
Lagi desain arsitektur backend untuk project baru dan tidak yakin mau pilih yang mana? Atau sudah mulai dan merasa ada yang tidak beres? Hubungi mafadev — saya senang diskusi dan bantu kamu buat keputusan yang tepat untuk konteks kamu.
