Belajar GraphQL - Sejarah dan Alasan Menggunakan GraphQL

#Pendahuluan

Sebelum kalian menulis satu baris schema, penting untuk memahami kenapa GraphQL ada. Teknologi bukan lahir dari ruang hampa; GraphQL lahir dari masalah nyata yang dihadapi Facebook saat mengembangkan aplikasi mobile pada awal 2010-an.

Episode 1 membedah tiga hal: sejarah dan evolusi GraphQL, masalah-masalah REST API yang menjadi pendorong lahirnya GraphQL, serta keunggulan GraphQL yang membuatnya diadopsi oleh GitHub, Shopify, dan Twitter. Kita juga akan membandingkan GraphQL dengan REST dan gRPC agar kalian tahu kapan memakai yang mana.

Kalian tidak perlu menghafal seluruh spesifikasi di episode ini. Yang lebih penting adalah membangun intuisi: masalah apa yang sedang dipecahkan, dan mengapa desain GraphQL menjawab masalah itu. Intuisi ini akan menjadi kompas kalian saat mulai menulis schema di episode 3.

Selain itu, siapkan pola pikir pemecahan masalah. Setiap teknologi di sini lahir karena sebuah rasa sakit — REST terlalu banyak endpoint, gRPC terlalu kaku untuk client publik — dan memahami rasa sakit tersebut lebih berharga daripada menghafal sintaks.

#Evolusi dan Sejarah GraphQL

#Lahir di Facebook Tahun 2012

GraphQL dikembangkan secara internal oleh tim Facebook pada tahun 2012, diprakarsai oleh Lee Byron, Nick Schrock, dan Dan Schafer. Motivasi utama mereka adalah pengalaman aplikasi iOS yang lambat karena harus mengambil data berlebih dari REST API. Aplikasi berita harus memuat daftar berita, tetapi setiap item membutuhkan komentar, like, dan metadata penulis — yang berarti beberapa round-trip HTTP untuk satu tampilan.

Pada tahun 2015, GraphQL di-open-source bersama dengan spesifikasi resminya. Sejak saat itu ekosistem tumbuh pesat: graphql-js menjadi implementasi referensi, dan komunitas membangun tooling di berbagai bahasa. Pada tahun 2018, GraphQL diserahkan ke GraphQL Foundation di bawah naungan Linux Foundation, menandakan bahwa GraphQL kini menjadi open standard yang netral vendor.

#Adopsi oleh Perusahaan Besar

Titik balik adopsi datang ketika perusahaan besar mempublikasikan kesuksesan mereka: GitHub meluncurkan GraphQL API v4, Shopify membangun GraphQL untuk semua aplikasi e-commerce, dan Twitter memakai GraphQL untuk aplikasi mobile. Pola yang berulang: tim mobile butuh data yang lebih presisi, dan tim backend ingin mengurangi jumlah endpoint.

Timeline yang perlu kalian ingat: 2012 konsep internal di Facebook, 2015 open-source dan rilis spesifikasi, 2018 masuk GraphQL Foundation, dan setelahnya ekosistem seperti Apollo, Relay, dan tooling modern matang hingga sekarang.

Salah satu bukti nyata bahwa GraphQL adalah open standard yang netral vendor adalah keberadaan spesifikasi resmi yang bisa diimplementasikan siapa saja. Posisi inilah yang membuat banyak perusahaan merasa aman berinvestasi: mereka tidak terikat pada satu vendor atau satu bahasa pemrograman.

Jika kalian penasaran bagaimana rasanya memakai API GraphQL yang sudah matang, coba akses GitHub GraphQL API yang tersedia lewat satu endpoint saja. Kirim query sederhana dengan curl 'https://api.github.com/graphql' dan amati bentuk request serta response-nya sebelum kalian membangun implementasi sendiri.

#Permasalahan dengan REST API

#Over-Fetching dan Under-Fetching

REST menganut prinsip resource yang diekspos lewat endpoint. Masalah pertama adalah over-fetching: sebuah endpoint mengembalikan seluruh representasi resource padahal client hanya butuh sebagian. Contoh nyata: endpoint /users/1 mengembalikan 20 kolom, sementara layar profil hanya menampilkan nama dan avatar.

Sebaliknya, under-fetching terjadi ketika satu tampilan butuh data dari beberapa resource. Untuk menampilkan halaman berita, client harus memanggil /posts, lalu untuk tiap post memanggil /posts/:id/comments — itulah cikal bakal masalah N+1 yang akan dibahas di episode 9. Beban jaringan berlipat dan aplikasi mobile terasa lambat.

#Endpoint Proliferation dan Versioning

Semakin banyak use case, semakin banyak endpoint: /users, /users/featured, /users/:id/posts, dan seterusnya. Ini disebut endpoint proliferation. Ditambah lagi, perubahan API memaksa versioning seperti /v1 dan /v2, memecah client dan menyulitkan evolusi. Di sisi dokumentasi, REST tidak memiliki contract yang terpusat, sehingga dokumentasi mudah tidak sinkron dengan implementasi.

Bayangkan berapa banyak endpoint yang harus dirawat ketika setiap kombinasi data membutuhkan URL baru. Setiap tambahan fitur berarti tambahan endpoint, tambahan dokumentasi, dan tambahan logika untuk menyelaraskan bentuk response. Di sisi client, setiap perubahan response berisiko memecah aplikasi yang sudah berjalan di production.

Masalah ini bukan sekadar kerapian kode, melainkan juga biaya tim. Endpoint yang menumpuk membuat onboarding anggota baru lebih lambat, karena tidak ada satu tempat pun yang merangkum keseluruhan kontrak data.

#Keunggulan GraphQL

#Single Endpoint dan Client-Specified Queries

GraphQL menawarkan satu endpoint yang menerima query terstruktur. Client menentukan persis kolom yang dibutuhkan:

query BeritaTerbaru {
  posts(first: 10) {
    id
    title
    author {
      name
    }
    comments {
      totalCount
    }
  }
}

Dengan query di atas, client mendapatkan data yang dibutuhkan dalam satu round-trip. Tidak ada over-fetching karena hanya kolom yang diminta yang dikembalikan, dan tidak ada under-fetching karena relasi bisa disatukan dalam satu query.

#Strongly Typed Schema dan Real-Time

Keunggulan lain yang akan kalian rasakan di episode 3: schema yang strongly typed dan self-documenting. Karena seluruh bentuk data didefinisikan dalam schema, editor bisa memberikan autocomplete dan validasi sebelum request dikirim. Introspection memungkinkan tooling menggambar dokumentasi otomatis. Ditambah kemampuan subscriptions untuk data real-time (episode 16), GraphQL menjadi solusi menyeluruh untuk kebutuhan data modern.

#GraphQL vs REST vs gRPC

#Tabel Perbandingan

#Kapan Memakai yang Mana

REST masih cocok untuk API publik sederhana, layanan yang mendominasi operasi CRUD, dan ekosistem yang sangat bergantung pada caching HTTP. gRPC unggul untuk komunikasi antar-service dengan performa tinggi, streaming, dan kebutuhan binary protocol. GraphQL paling cocok ketika client beragam — web, mobile, dan third-party — yang membutuhkan fleksibilitas mengambil data, serta ketika over-fetching mulai menjadi masalah nyata.

{
  "rest": "/users/1",
  "graphql": "query { user(id: 1) { name avatar } }",
  "grpc": "GetUserRequest { user_id: 1 }"
}

Praktik umum di industri: pakai GraphQL sebagai API layer untuk client, dan biarkan komunikasi internal antar-service memakai REST atau gRPC. Pola inilah yang akan kita bangun di fase 4 dan 8.

Keputusan akhir selalu bergantung pada konteks tim dan kebutuhan produk. Ada tim yang memulai dari REST lalu berpindah ke GraphQL ketika jumlah endpoint mulai sulit dikendalikan; ada pula yang langsung memakai GraphQL karena sejak awal tahu client-nya beragam.

Yang perlu diperhatikan bukan label teknologinya, melainkan seberapa cepat tim bisa mengirim fitur tanpa patah di tengah jalan. Teknologi yang paling tepat adalah yang paling sesuai dengan bentuk tim dan produk kalian.

Di fase berikutnya kalian akan melihat bagaimana pola ini diterapkan: GraphQL di depan untuk client, REST atau gRPC di belakang untuk antar-service. Peta besar inilah yang akan membentuk arsitektur yang kita bangun sepanjang series.

#Penutup

Inti yang harus dibawa pulang:

• GraphQL lahir di Facebook tahun 2012 untuk mengatasi masalah data di aplikasi mobile, dan di-open-source tahun 2015.
• REST rentan terhadap over-fetching, under-fetching, endpoint proliferation, dan versioning complexity.
• GraphQL menawarkan satu endpoint, client-specified queries, schema yang strongly typed dan self-documenting.
• Subscriptions membuat GraphQL cocok untuk fitur real-time.
• GraphQL, REST, dan gRPC punya posisi masing-masing; GraphQL paling unggul sebagai API layer untuk client yang beragam.

Di episode 2 selanjutnya kalian akan mempelajari konsep dasar dan arsitektur GraphQL — bagaimana request di-parse, divalidasi, dan dieksekusi, komponen-komponen utama seperti SDL, type system, dan resolver, hingga pola arsitektur seperti gateway dan federation. Persiapkan diri kalian untuk masuk ke bagian paling teknis dari series ini!