GraphQL vs REST bukan soal mana yang lebih modern, tapi siapa yang mengendalikan bentuk data. Di REST, server menentukan bentuk respons per endpoint. Di GraphQL, klien menulis query untuk meminta field yang dibutuhkan dari satu endpoint. REST lebih sederhana dan mudah di-cache, cocok untuk sebagian besar aplikasi. GraphQL unggul saat banyak klien berbeda butuh kombinasi data yang bervariasi.
Cara Kerja Masing-masing
REST
GET /api/orders/123
GET /api/orders/123/items
GET /api/customers/45
Setiap sumber daya punya URL sendiri, dan metode HTTP (GET, POST, PUT, DELETE) menunjukkan aksinya.
GraphQL
POST /graphql
query {
order(id: 123) {
number
total
items { name qty }
customer { name phone }
}
}
Satu request mengambil pesanan, item, dan pelanggan, persis dengan field yang diminta.
Perbandingan GraphQL vs REST
| Aspek | REST | GraphQL |
|---|---|---|
| Bentuk data | Ditentukan server | Ditentukan klien |
| Over-fetching / under-fetching | Sering terjadi | Jarang |
| Caching HTTP | Mudah (URL + GET) | Lebih sulit, butuh cache di klien atau persisted query |
| Kurva belajar | Rendah | Sedang sampai tinggi |
| Dokumentasi | OpenAPI (perlu dirawat) | Skema bertipe bawaan |
| Upload file | Sederhana | Butuh spesifikasi tambahan |
| Kontrol beban server | Mudah diprediksi per endpoint | Perlu batas kedalaman dan kompleksitas query |
| Versi API | /v1, /v2 | Evolusi skema dengan field deprecated |
Kapan REST Lebih Tepat
- Satu atau dua klien (web dan mobile) dengan kebutuhan data yang mirip.
- API publik untuk pihak ketiga yang mengharapkan pola standar.
- Butuh caching agresif di CDN.
- Tim kecil yang ingin cepat produktif. Panduan membangunnya ada di REST API dengan Laravel Sanctum.
Kapan GraphQL Lebih Tepat
- Banyak klien berbeda (web, mobile, dashboard internal, mitra) dengan kebutuhan data yang bervariasi.
- Data sangat relasional dan sering diambil dalam kombinasi yang berbeda.
- Tim frontend ingin bergerak cepat tanpa menunggu endpoint baru dibuat.
- Menyatukan beberapa layanan backend di balik satu gateway.
Biaya Tersembunyi GraphQL
- Masalah N+1 di resolver. Query yang meminta 50 pesanan beserta pelanggannya bisa memicu 51 query database. Gunakan DataLoader atau eager loading di resolver.
- Query yang terlalu berat. Klien bisa meminta relasi bersarang sangat dalam. Batasi kedalaman, kompleksitas, dan jumlah item.
- Otorisasi per field. Karena klien bebas memilih field, setiap field sensitif perlu aturan akses sendiri.
- Introspeksi di production membuka seluruh skema ke publik. Pertimbangkan untuk mematikannya bila API bukan untuk umum.
- Pemantauan. Semua request masuk ke satu endpoint, jadi log per URL tidak lagi informatif; perlu pencatatan per nama operasi.
Menerapkan di Laravel
- REST: route API, controller, Form Request, dan API Resource bawaan Laravel.
- GraphQL: paket seperti Lighthouse memungkinkan skema ditulis dalam bahasa skema GraphQL dan dihubungkan ke model Eloquent dengan directive.
type Query {
order(id: ID! @eq): Order @find
orders: [Order!]! @paginate(defaultCount: 20)
}
type Order {
id: ID!
number: String!
total: Int!
customer: Customer! @belongsTo
items: [OrderItem!]! @hasMany
}
Contoh Keputusan
Sebuah toko online punya website, aplikasi Android, dan dashboard gudang. Website dan aplikasi menampilkan data produk yang hampir sama, sedangkan dashboard gudang butuh data stok yang sangat berbeda. Pilihan yang masuk akal: REST untuk website dan aplikasi (data mirip, bisa di-cache di CDN), plus beberapa endpoint khusus untuk dashboard gudang. GraphQL baru layak dipertimbangkan ketika jumlah klien bertambah dan tim backend kewalahan membuat endpoint baru untuk setiap layar.
Alternatif di Tengah
- REST dengan parameter field dan include, misalnya
GET /orders/123?include=items,customer, sudah menyelesaikan sebagian besar masalah over-fetching. Paket seperti spatie/laravel-query-builder memudahkannya. - Endpoint khusus per layar (Backend for Frontend) untuk klien mobile yang butuh data ringkas.
Kesalahan yang Sering Terjadi
- Memilih GraphQL karena tren untuk aplikasi dengan satu klien dan kebutuhan data sederhana.
- REST yang tidak konsisten: format error, pagination, dan penamaan berbeda di setiap endpoint.
- GraphQL tanpa batas query, sehingga satu query nakal bisa membebani database.
Langkah Berikutnya
Apa pun pilihannya, performa database menentukan kecepatan API. Pelajari MySQL performance tuning. Kalau kamu butuh layanan API terpisah dengan Python, lihat FastAPI untuk microservice.