Kapan Harus Berpindah ke GraphQL dan meninggalkan REST API ?

Belakangan ini pada beberapa kesempatan saya kerap diberikan pertanyaan mengenai GraphQL vs REST API, mana yang lebih baik di antara keduanya, kapan sebaiknya berpindah dari REST API untuk menggunakan full GraphQL. Tentunya menjawab pertanyaan-pertanyaan ini tidak semudah yang dibayangkan dan sangat tergantung dengan kasusnya. Yang pasti diperlukan pemahaman terlebih dahulu mengenai keduanya sebelum anda memilih salah satu stack untuk diimplementasikan pada project anda berikutnya. Untuk memahami REST dan GraphQL kita harus mendalami sejarah pengembangan dan penggunaannya.

REST API

REST (Representational State Transfer) telah menjadi arsitektur dominan dalam pengembangan API selama bertahun-tahun. Semenjak kemunculannya pertama kali pada tahun 2000 oleh Roy Fielding yakni salah satu co-founder Apache HTTP server, REST kerap menjadi protokol standar dalam pertukaran data di internet. Standar ini mengglobal dan hampir digunakan oleh seluruh aplikasi Web, Tablet, Mobile, dll. REST membagi bentuk request menggunakan method GET, POST, PUT, DELETE, dan PATCH, yang dikombinasikan dengan HTTP response Code 2xx untuk berhasil, 3xx untuk redirection, 4xx client error, dan 5xx server error. Sehingga kita sering menemui request dan response sebagai berikut

GET https://api.fadhlizakiy.com/events => 200 Response OK

POST https://api.fadhlizakiy.com/events/create => 502 Server Error

GraphQL

Pada tahun 2012, sekumpulan engineer facebook, didasari oleh kesulitannya dalam me-manage banyaknya API endpoint, mengembangkan suatu mekanisme data fetching yang deklaratif di mana client dapat menentukan sendiri data yang dibutuhkan dari API alih-alih menembak beberapa API endpoint. Mekanisme ini kemudian yang dikenal dengan nama GraphQL yang dibuat menjadi suatu open source di bawah yayasan Linux. GraphQL tidak mempedulikan database, storage, maupun bahasa yang digunakan untuk melakukan routing.

GraphQL secara umum hanya memiliki satu endpoint, domain.com/graphql yang dapat digunakan untuk semuanya. Data yang dapat dipanggil pun juga bergantung pada client yang membutuhkannya, contoh memanggil nama dan umur, dari current user cukup menggunakan query berikut pada payload graphql.

query CurrentUser {
  currentUser {
    name
    age
  }
}

Kapan waktu yang tepat untuk berpindah dari REST API ke GraphQL?

Dengan kemunculan GraphQL, banyak developer mulai mempertimbangkan untuk beralih ke teknologi yang lebih baru ini. Tentunya tidak salah menggunakan teknologi GraphQL namun anda harus memahami terlabih dahulu bahwa GraphQL tetaplah suatu HTTP Request, tetap membutuhkan bridging (model) koneksi ke database, dan tetap perlu dijalankan / diproses menggunakan kode pemrograman web baik PHP, NodeJS, GoLang, Python, JAVA, etc.

Berikut beberapa point yang menurut saya juga dapat menjadi bahan pertimbangan sebelum anda memigrasi REST API anda menjadi GraphQL sebagai berikut :

1. Kebutuhan Kompleksitas Permintaan Data

Jika aplikasi anda memiliki kebutuhan yang kompleks terkait dengan pemilihan data yang spesifik, GraphQL dapat menjadi solusi yang lebih efisien. REST API cenderung menyediakan data yang sudah ditentukan oleh endpoint, sementara GraphQL memungkinkan klien untuk menentukan struktur dan jumlah data yang diinginkan.

Meskippun GraphQL menawarkan fleksibilitas yang luar biasa dalam hal mengambil data dari server, namun anda juga harus pahami banyak data dari dalam satu tabel yang anda tidak inginkan client untuk melihatnya, apalagi mengubahnya. Sehingga tidak sedikit developer harus menambahkan kode-kode “perlindungan” untuk membatasi client agar tidak membuka informasi rahasia, dan melakukan mutasi (bahasa GraphQL dalam melakukan pengubahan data dalam basis data).

2. Efisiensi Penggunaan Bandwidth

Dalam GraphQL, satu permintaan dapat digunakan untuk mendapatkan semua data yang dibutuhkan, mengurangi jumlah permintaan dan respons yang perlu dikirim dan diterima. Hal ini merupakan salah satu kelebihan utama GraphQL dalam melakukan efisiensi penggunaan bandwidth. Dengan REST, client sering kali harus mengakses beberapa endpoint untuk mengumpulkan semua informasi yang diperlukan.

Fitur ini tidak serta merta membuat permintaan ke dalam basisdata anda terpetakan dengan baik layaknya menggunakan ORM. Khususnya mengambil data agregat, atau kasus JOIN tabel yang kompleks dari beberapa tabel tetap dibutuhkan kepiawaian developer dalam membentuk model-nya.

3. Pengembangan Aplikasi Frontend yang Lebih Efisien

GraphQL memungkinkan frontend developer untuk mengambil tepat data yang diperlukan untuk tampilan tertentu. Hal ini meminimalkan over-fetching, di mana client mengambil lebih banyak data daripada yang diperlukan, dan under-fetching, di mana client tidak mendapatkan cukup data. Dengan kontrol yang lebih besar atas data yang diterima, developer dapat membuat aplikasi yang lebih efisien dan responsif.

4. Skala Pengembangan Tim

Jika tim pengembangan Anda terdiri dari kelompok yang bekerja pada bagian-bagian aplikasi yang berbeda, GraphQL dapat mempermudah kerja sama. Karena klien dapat menentukan sendiri struktur data yang diinginkan, tim frontend dan backend dapat bekerja secara independen tanpa terlalu bergantung pada perubahan pada sisi lain.

5. Migrasi Bertahap

Pindah dari REST ke GraphQL tidak harus tiba-tiba. Banyak developer di berbagai belahan dunia berhasil melakukan migrasi bertahap dengan memperkenalkan GraphQL secara perlahan dan menyesuaikan satu bagian aplikasi pada satu waktu. Khususnya sangat bermanfaat pada aplikasi yang memiliki kebutuhan data yang kompleks.

Jadi Kapan Waktu Terbaik ?

Waktu terbaik untuk beralih dari REST ke GraphQL bergantung pada kebutuhan proyek dan tim pengembangan Anda. Jika Anda menghadapi kompleksitas dalam pengambilan data, efisiensi bandwidth yang kritis, atau perlu meningkatkan keterlibatan antara frontend dan backend, maka mungkin saja merupakan waktu yang tepat. Penting untuk mengevaluasi keuntungan dan tantangan yang terkait dengan masing-masing teknologi sebelum membuat keputusan. Migrasi ke GraphQL dapat membuka peluang baru untuk efisiensi dan skalabilitas, tetapi perlu dipertimbangkan dengan hati-hati untuk memastikan keberhasilan transisi.