GraphQL: Gambaran Alternatif REST

Memesan lauk satu per satu vs paket hemat

Restoran REST menyajikan "paket hemat": setiap endpoint mengembalikan set menu tetap. Mau nasinya saja? Tetap dapat paket lengkap. GraphQL seperti memesan lauk satu per satu: klien menulis persis data apa yang dibutuhkan, server mengembalikan tepat itu, tidak lebih tidak kurang. Satu endpoint /graphql melayani semua kebutuhan.

Kenapa GraphQL lahir

Aplikasi mobile membenci pemborosan: layar kecil hanya butuh 3 field, tapi endpoint REST mengembalikan 30 field. Itu over-fetching (kebanyakan data). Sebaliknya, halaman kompleks butuh data dari 5 endpoint berbeda: 5 request berurutan (under-fetching). GraphQL menyelesaikan keduanya: satu request, data pas.

Contoh 1: query GraphQL

query {
  produk(id: 1) {
    nama
    harga
    ulasan(limit: 3) {
      bintang
      komentar
    }
  }
}

Response:

{
  "data": {
    "produk": {
      "nama": "Kopi Tubruk",
      "harga": 15000,
      "ulasan": [
        {"bintang": 5, "komentar": "Mantap!"},
        {"bintang": 4, "komentar": "Enak"}
      ]
    }
  }
}

Satu request menggantikan GET /produk/1 + GET /produk/1/ulasan. Klien yang menentukan bentuk response, bukan server.

Contoh 2: kapan tetap pakai REST

GraphQL bukan pengganti universal. REST unggul untuk: API publik sederhana (caching HTTP bekerja natural), upload file (GraphQL butuh ekstensi khusus), dan tim kecil (setup GraphQL lebih berat: schema, resolver, DataLoader). Aturan praktis: butuh fleksibilitas query tinggi dan banyak klien berbeda? GraphQL. CRUD standar dengan tim kecil? REST cukup.

Kesalahan umum

Salah: memakai GraphQL untuk semua hal. Kompleksitas tanpa manfaat. Yang benar: evaluasi kebutuhan dulu.

Salah: tidak membatasi kedalaman query. Query jahat bisa meminta relasi 20 level dalam dan melumpuhkan server. Yang benar: batasi depth dan complexity di server.

Salah: N+1 query di resolver. Setiap item memicu query database terpisah. Yang benar: pakai DataLoader untuk batching.

Salah: mengira GraphQL otomatis aman dari over-fetching di server. Server tetap mengambil semua kolom kalau resolver-nya malas. Yang benar: optimasi resolver sesuai field yang diminta.

Contoh mutation (mengubah data)

GraphQL tidak hanya membaca; mutation untuk menulis:

mutation {
  buatProduk(nama: "Kopi Susu", harga: 18000) {
    id
    nama
  }
}

Response:

{
  "data": {
    "buatProduk": { "id": 9, "nama": "Kopi Susu" }
  }
}

Perhatikan kamu tetap memilih field yang dikembalikan (id dan nama saja). Prinsipnya sama dengan query: server tidak mengirim data yang tidak diminta. Untuk upload file atau operasi sangat sederhana, REST biasanya tetap lebih praktis.

Satu keunggulan GraphQL yang jarang dibahas: introspection. Klien bisa bertanya ke server "schema-mu apa saja?" dan mendapat dokumentasi otomatis yang selalu akurat. Tools seperti GraphiQL memakai ini untuk autocomplete query. Dokumentasi yang tidak pernah basi karena di-generate dari kode.

Catatan teknis: Coba GraphQL tanpa setup: GitHub GraphQL Explorer (docs.github.com/graphql) memungkinkanmu menjalankan query langsung di browser dengan token pribadimu. Pengalaman langsung ini lebih menjelaskan daripada seratus halaman teori.