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

AspekRESTGraphQL
Bentuk dataDitentukan serverDitentukan klien
Over-fetching / under-fetchingSering terjadiJarang
Caching HTTPMudah (URL + GET)Lebih sulit, butuh cache di klien atau persisted query
Kurva belajarRendahSedang sampai tinggi
DokumentasiOpenAPI (perlu dirawat)Skema bertipe bawaan
Upload fileSederhanaButuh spesifikasi tambahan
Kontrol beban serverMudah diprediksi per endpointPerlu batas kedalaman dan kompleksitas query
Versi API/v1, /v2Evolusi 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.