Apidog

Platform Pengembangan API Kolaboratif All-in-one

Desain API

Dokumentasi API

Debug API

Mocking API

Pengujian Otomatis

Panggilan RPC, REST dan GraphQL: Penjelasan Lengkap

Rebecca Kovács

Rebecca Kovács

Updated on May 20, 2025

Dalam pengembangan perangkat lunak modern, aplikasi jarang berdiri sendiri. Mereka berkomunikasi, bertukar data, dan memicu tindakan satu sama lain, membentuk ekosistem yang luas dan saling terhubung. Komunikasi ini diatur oleh Application Programming Interfaces (API), yang mendefinisikan aturan dan protokol tentang bagaimana komponen perangkat lunak yang berbeda berinteraksi. Selama beberapa dekade, beberapa gaya arsitektur dan protokol telah muncul untuk memfasilitasi komunikasi antar-layanan ini. Di antara yang paling menonjol adalah Remote Procedure Calls (RPC), Representational State Transfer (REST), dan GraphQL.

Memahami ketiga paradigma ini sangat penting bagi setiap pengembang atau arsitek yang merancang sistem terdistribusi. Masing-masing memiliki filosofi, kekuatan, kelemahan, dan kasus penggunaan idealnya sendiri. Artikel ini bertujuan untuk menjelaskan RPC, REST, dan GraphQL secara jelas, menggali konsep inti, mekanisme operasional, manfaat, kekurangan, dan skenario di mana masing-masing unggul.

💡
Ingin alat Pengujian API yang hebat yang menghasilkan Dokumentasi API yang indah?

Ingin platform All-in-One yang terintegrasi untuk Tim Pengembang Anda bekerja sama dengan produktivitas maksimum?

Apidog memenuhi semua kebutuhan Anda, dan menggantikan Postman dengan harga yang jauh lebih terjangkau!
button

Dasar: Komunikasi Klien-Server

Sebelum menyelami detailnya, penting untuk memahami model fundamental yang semuanya layani: komunikasi klien-server. Dalam model ini, sebuah klien (misalnya, browser web, aplikasi seluler, server lain) membutuhkan beberapa data atau ingin melakukan suatu tindakan. Secara bersamaan, sebuah server (mesin atau proses jarak jauh) menyimpan data atau logika untuk melakukan tindakan tersebut. Klien mengirimkan permintaan ke server, dan server mengirimkan kembali respons. Mekanisme yang akan kita bahas – RPC, REST, dan GraphQL – adalah cara yang berbeda untuk menyusun permintaan dan respons ini.

RPC: Memanggil Fungsi Melalui Jaringan

Apa itu RPC?

Remote Procedure Call mewakili salah satu paradigma paling awal dan paling langsung untuk komunikasi antar-proses. Ide dasarnya adalah membuat permintaan ke server jarak jauh tampak dan beroperasi seperti panggilan fungsi atau prosedur lokal. Aplikasi klien memanggil apa yang tampak sebagai fungsi lokal (prosedur), tetapi eksekusi fungsi ini sebenarnya terjadi di server jarak jauh. Kerumitan komunikasi jaringan dihilangkan secara hati-hati, memberikan pemrograman terdistribusi kesan kesederhanaan yang mirip dengan pemrograman tradisional, mesin tunggal.

Cara Kerja RPC:

Proses RPC berlangsung melalui urutan langkah-langkah yang terkoordinasi, yang dirancang untuk membuat eksekusi jarak jauh menjadi transparan. Awalnya, klien memiliki "stub" atau "proxy" untuk prosedur jarak jauh. Stub ini mencerminkan tanda tangan prosedur jarak jauh yang sebenarnya. Ketika aplikasi klien memanggil stub ini, logika tidak dieksekusi secara lokal. Sebaliknya, stub klien mengambil parameter yang diteruskan ke fungsi dan "memarshall" atau "menserialisasikan" parameter tersebut. Langkah penting ini mengubah parameter dari representasi dalam memori mereka menjadi format yang cocok untuk transmisi jaringan, seperti biner, XML, atau JSON.

Setelah marshalling, parameter yang diserialisasikan ini, disertai dengan pengenal untuk prosedur spesifik yang akan dipanggil, dikirim melalui jaringan ke server. Di sisi server, "skeleton" atau stub sisi server menunggu dan menerima permintaan yang masuk. Skeleton server ini kemudian melakukan tugas "unmarshalling" atau "deserialisasi" data yang diterima, mengubahnya kembali menjadi parameter yang diharapkan oleh prosedur server yang sebenarnya.

Dengan parameter berhasil direkonstruksi, skeleton server memanggil prosedur yang ditentukan di server, meneruskan parameter yang telah di-unmarshal. Setelah prosedur menyelesaikan eksekusinya, nilai kembaliannya, bersama dengan pengecualian yang ditemui, di-marshall oleh skeleton server. Respons yang diserialisasikan ini kemudian ditransmisikan kembali melalui jaringan ke stub klien. Setelah menerima respons, stub klien meng-unmarshal-nya, mengubah data kembali menjadi nilai kembalian yang dapat langsung dipahami oleh aplikasi klien. Akhirnya, stub klien mengembalikan nilai ini ke kode pemanggil asli, sehingga melengkapi ilusi bahwa panggilan fungsi lokal telah dilakukan.

Karakteristik Utama RPC:

API RPC biasanya berorientasi tindakan. Mereka dirancang berdasarkan kata kerja atau perintah, seperti addUser(userDetails) atau calculatePrice(itemId, quantity). Fokus utamanya adalah pada "tindakan apa yang dapat Anda lakukan".

Secara tradisional, klien dan server dalam sistem RPC menunjukkan keterkaitan yang erat. Klien sering kali memerlukan pengetahuan eksplisit tentang nama fungsi spesifik dan tanda tangan parameter yang tepat yang tersedia di server. Akibatnya, modifikasi di sisi server sering kali memerlukan perubahan yang sesuai di sisi klien.

Framework RPC umumnya menyediakan alat untuk menghasilkan stub klien dan skeleton server dalam berbagai bahasa pemrograman dari Interface Definition Language (IDL) yang dibagikan. Contoh IDL termasuk CORBA IDL, Protocol Buffers (file .proto), atau Apache Thrift IDL. Kemampuan pembuatan kode ini memfasilitasi interoperabilitas.

Mengenai efisiensi, banyak protokol RPC, terutama yang menggunakan format biner, direkayasa untuk kinerja optimal dalam hal ukuran data dan kecepatan pemrosesan.

Evolusi: gRPC

Meskipun implementasi RPC sebelumnya seperti XML-RPC atau Java RMI memiliki keterbatasan tertentu, paradigma RPC telah mengalami kebangkitan yang signifikan dengan munculnya framework modern seperti gRPC (Google RPC). gRPC memperkenalkan peningkatan substansial. Ini didominasi menggunakan Protocol Buffers sebagai IDL dan untuk serialisasi pesan. Protocol Buffers menawarkan mekanisme yang agnostik bahasa, netral platform, dapat diperluas untuk menserialisasikan data terstruktur, sering digambarkan sebagai alternatif yang lebih ringkas, lebih cepat, dan lebih sederhana daripada XML.

Selain itu, gRPC beroperasi melalui HTTP/2, yang memungkinkan fitur-fitur canggih seperti multiplexing (memungkinkan banyak permintaan dan respons melalui satu koneksi), kemampuan server push, dan kompresi header. Fitur-fitur ini secara kolektif berkontribusi pada peningkatan kinerja dan pengurangan latensi.

Kekuatan gRPC yang patut diperhatikan adalah dukungannya untuk berbagai mode streaming. Ini termasuk unary (pola permintaan-respons sederhana), server streaming (di mana klien mengirimkan permintaan, dan server merespons dengan aliran pesan), client streaming (di mana klien mengirimkan aliran pesan, dan server mengeluarkan satu respons), dan bidirectional streaming (di mana klien dan server dapat mengirimkan aliran pesan secara independen).

Terakhir, gRPC menyediakan alat yang kuat untuk pembuatan kode, memungkinkan pembuatan otomatis kode klien dan server dalam berbagai bahasa pemrograman populer.

Keunggulan RPC (terutama RPC modern seperti gRPC):

  • Kinerja: Ini bisa sangat berkinerja tinggi, terutama saat menggunakan protokol biner seperti Protocol Buffers bersama dengan HTTP/2. Latensi rendah adalah manfaat utama.
  • Kesederhanaan (bagi pengembang): Abstraksi panggilan jarak jauh sebagai fungsi lokal dapat secara signifikan menyederhanakan upaya pengembangan, terutama untuk microservice internal.
  • Kontrak Berjenis Kuat: IDL memberlakukan kontrak yang jelas dan tidak ambigu antara klien dan server, yang membantu dalam menangkap kesalahan integrasi selama waktu kompilasi.
  • Kemampuan Streaming: Ini unggul dalam skenario yang menuntut aliran data real-time atau transfer dataset besar.
  • Pembuatan Kode: Pembuatan otomatis library klien dan stub server mengurangi jumlah kode boilerplate yang perlu ditulis pengembang.

Kekurangan RPC:

  • Keterkaitan Erat: Bahkan dengan penggunaan IDL, perubahan pada tanda tangan prosedur sering kali memerlukan pembuatan ulang dan penyebaran ulang kode klien dan server.
  • Kemudahan Penemuan (Discoverability): Tidak seperti REST, tidak ada metode standar untuk menemukan prosedur yang tersedia atau strukturnya tanpa akses sebelumnya ke IDL atau dokumentasi terkait.
  • Kurang Ramah Browser (Secara Historis): Mekanisme RPC tradisional tidak semudah diintegrasikan langsung dengan browser web dibandingkan dengan REST. Meskipun gRPC-Web bertujuan untuk menjembatani kesenjangan ini, biasanya memerlukan lapisan proxy.
  • Traversal Firewall: Mekanisme RPC berbasis non-HTTP terkadang dapat mengalami kesulitan dengan firewall yang sebagian besar dikonfigurasi untuk mengizinkan lalu lintas HTTP. gRPC, dengan menggunakan HTTP/2, sebagian besar mengurangi kekhawatiran ini.

Kapan Menggunakan RPC:

Pertimbangkan RPC untuk komunikasi microservice internal di mana kinerja dan latensi rendah adalah tujuan desain yang kritis. Ini juga cocok untuk aplikasi yang memerlukan streaming data yang kompleks dan berkinerja tinggi. Jika kontrak yang jelas dan berjenis kuat antara layanan diinginkan, RPC menawarkan keuntungan signifikan. Lingkungan polyglot, di mana pembuatan kode untuk banyak bahasa dapat memperlancar pengembangan, juga mendapat manfaat dari RPC. Terakhir, di lingkungan dengan keterbatasan jaringan di mana efisiensi ukuran pesan sangat penting, RPC, terutama gRPC dengan Protocol Buffers, adalah kandidat yang kuat.

REST: Sumber Daya dan Hypermedia

Apa itu REST?

REST, atau Representational State Transfer, bukanlah protokol atau standar yang kaku, melainkan gaya arsitektur untuk merancang aplikasi jaringan. Ini didefinisikan dengan cermat oleh Roy Fielding dalam disertasi doktoralnya tahun 2000. REST dengan cerdik memanfaatkan fitur dan protokol HTTP yang ada, menekankan mode komunikasi yang stateless, klien-server, dan cacheable. Konsep sentral berkisar pada sumber daya (entitas data) yang diidentifikasi secara unik oleh URL, dan interaksi dengan sumber daya ini dilakukan menggunakan metode HTTP standar.

Prinsip Inti REST (Kendala):

Gaya arsitektur REST ditentukan oleh beberapa kendala panduan:

Prinsip fundamental adalah Arsitektur Klien-Server. Ini mensyaratkan pemisahan perhatian yang jelas. Klien bertanggung jawab atas antarmuka pengguna dan aspek pengalaman pengguna, sementara server mengelola penyimpanan data, logika bisnis, dan penyediaan API itu sendiri.

Kendala penting lainnya adalah Statelessness. Setiap permintaan yang dikirim dari klien ke server harus merangkum semua informasi yang diperlukan agar server memahami dan memproses permintaan tersebut. Server tidak menyimpan konteks klien apa pun (status sesi) di antara permintaan individual. Setiap status yang relevan dengan sesi dipertahankan di sisi klien.

Cacheability juga merupakan prinsip utama. Respons yang dihasilkan oleh server harus secara eksplisit mendefinisikan dirinya sebagai cacheable atau non-cacheable. Ini memungkinkan klien dan sistem perantara (seperti Content Delivery Networks atau CDN) untuk menyimpan respons, yang dapat secara signifikan meningkatkan kinerja dan skalabilitas.

Sistem REST dirancang sebagai Sistem Berlapis. Ini berarti klien biasanya tidak dapat memastikan apakah ia terhubung langsung ke server akhir atau ke perantara (seperti load balancer atau proxy) di sepanjang jalur komunikasi. Server perantara dapat meningkatkan skalabilitas sistem dengan memfasilitasi load balancing dan menyediakan cache bersama.

Kendala Uniform Interface bisa dibilang yang paling membedakan REST dan berfungsi untuk menyederhanakan dan memisahkan arsitektur. Kendala ini selanjutnya dipecah menjadi beberapa sub-kendala.

Pertama, Identifikasi Sumber Daya: Semua sumber daya konseptual diidentifikasi dalam permintaan menggunakan URI (Uniform Resource Identifiers), biasanya URL. Misalnya, /users/123 secara unik mengidentifikasi sumber daya pengguna tertentu.

Kedua, Manipulasi Sumber Daya Melalui Representasi: Klien berinteraksi dengan sumber daya bukan dengan memanggil metode secara langsung pada sumber daya tersebut, tetapi dengan bertukar representasi dari sumber daya ini. Representasi dapat dalam berbagai format, seperti JSON, XML, atau HTML. Klien menunjukkan format pilihannya menggunakan header Accept, sementara server menentukan format representasi yang dikirim menggunakan header Content-Type.

Ketiga, Pesan yang Deskriptif Diri (Self-Descriptive Messages): Setiap pesan yang dipertukarkan harus berisi informasi yang cukup untuk menjelaskan bagaimana pesan tersebut harus diproses. Misalnya, header HTTP seperti Content-Type dan Content-Length menyediakan metadata tentang isi pesan, dan kode status memberi tahu klien tentang hasil permintaannya.

Keempat, Hypermedia as the Engine of Application State (HATEOAS): Prinsip ini, sering dianggap sebagai aspek REST yang paling canggih dan terkadang paling sedikit diimplementasikan, mendikte bahwa respons server harus menyertakan tautan (hypermedia). Tautan ini memandu klien dengan menunjukkan tindakan apa yang dapat diambil selanjutnya atau sumber daya terkait apa yang dapat diaksesnya. Ini memungkinkan klien untuk menavigasi API secara dinamis, daripada mengandalkan URI yang di-hardcode. Misalnya, respons untuk sumber daya pengguna mungkin menyertakan tautan untuk melihat pesanan mereka atau memperbarui detail profil mereka.

Kendala opsional adalah Code on Demand. Ini memungkinkan server untuk sementara memperluas atau menyesuaikan fungsionalitas klien dengan mentransfer kode yang dapat dieksekusi, seperti cuplikan JavaScript.

Cara Kerja REST:

Dalam sistem RESTful, semuanya dikonseptualisasikan sebagai sumber daya (misalnya, pengguna, produk, pesanan). Setiap sumber daya diidentifikasi secara unik oleh URI. Misalnya, GET /users mungkin mengambil daftar pengguna, sementara GET /users/123 mengambil pengguna spesifik dengan ID 123.

Metode HTTP (Verbs) standar digunakan untuk melakukan tindakan pada sumber daya ini. GET digunakan untuk mengambil sumber daya. POST biasanya membuat sumber daya baru atau dapat digunakan untuk memicu proses, dengan data untuk sumber daya baru dikirim dalam isi permintaan. PUT digunakan untuk memperbarui sumber daya yang ada, biasanya memerlukan penggantian penuh data sumber daya, dan bersifat idempotent (beberapa permintaan identik memiliki efek yang sama dengan satu permintaan). DELETE menghapus sumber daya. PATCH memungkinkan pembaruan parsial pada sumber daya yang ada. HEAD mengambil metadata tentang sumber daya, mirip dengan GET tetapi tanpa isi respons. OPTIONS digunakan untuk mendapatkan informasi tentang opsi komunikasi untuk sumber daya target.

Kode Status, yang merupakan bagian dari standar HTTP, digunakan untuk menunjukkan hasil permintaan. Contohnya termasuk 200 OK, 201 Created untuk pembuatan yang berhasil, 400 Bad Request untuk kesalahan klien, 404 Not Found ketika sumber daya tidak ada, dan 500 Internal Server Error untuk masalah sisi server.

Mengenai Format Data, JSON (JavaScript Object Notation) telah menjadi format yang paling umum untuk bertukar data dalam API REST karena sifatnya yang ringan dan kemudahan parsing. Namun, XML, HTML, atau bahkan teks biasa juga dapat digunakan.

Keunggulan REST:

  • Kesederhanaan dan Keakraban: Ini memanfaatkan standar HTTP yang sudah dipahami dengan baik, membuatnya relatif mudah dipelajari, diimplementasikan, dan dikonsumsi.
  • Statelessness: Ini menyederhanakan desain server dan meningkatkan skalabilitas karena server tidak perlu menyimpan informasi sesi klien di antara permintaan.
  • Cacheability: Mekanisme caching HTTP dapat langsung dan efektif digunakan untuk meningkatkan kinerja dan mengurangi beban server.
  • Dekopling: Klien dan server terpisah. Selama URI sumber daya dan kontrak metode tetap konsisten, implementasi yang mendasarinya di kedua sisi dapat berkembang secara independen.
  • Kemudahan Penemuan (dengan HATEOAS): Ketika HATEOAS diimplementasikan dengan benar, klien dapat secara dinamis menemukan tindakan yang tersedia dan menavigasi melalui sumber daya, membuat API lebih fleksibel dan dapat berkembang.
  • Adopsi Luas dan Alat: Ada ekosistem alat, library, SDK klien, dan gateway yang luas yang mendukung API RESTful. Ini secara inheren ramah browser.
  • Mudah Dibaca Manusia: URI sering dirancang agar mudah dibaca manusia, dan format data umum seperti JSON mudah bagi pengembang untuk diperiksa dan di-debug.

Kekurangan REST:

  • Over-fetching dan Under-fetching: Ini adalah masalah umum.
  • Over-fetching terjadi ketika sebuah endpoint mengembalikan lebih banyak data daripada yang sebenarnya dibutuhkan klien untuk tugas tertentu. Misalnya, untuk menampilkan daftar nama pengguna, endpoint /users mungkin mengembalikan objek pengguna lengkap termasuk alamat, nomor telepon, dan detail lainnya untuk setiap pengguna, yang sebagian besar mungkin tidak digunakan.
  • Under-fetching terjadi ketika klien perlu membuat beberapa permintaan ke endpoint yang berbeda untuk mengumpulkan semua data yang dibutuhkan untuk tampilan lengkap. Misalnya, untuk mendapatkan detail pengguna dan posting terbaru mereka, klien mungkin perlu memanggil /users/{id} terlebih dahulu dan kemudian melakukan panggilan terpisah ke /users/{id}/posts.
  • Multiple Round Trips: Masalah under-fetching sering menyebabkan beberapa perjalanan bolak-balik jaringan, yang dapat meningkatkan latensi dan berdampak negatif pada pengalaman pengguna, terutama pada jaringan seluler atau yang tidak stabil.
  • Tantangan Versi: Mengembangkan API REST tanpa merusak klien yang ada bisa menjadi tantangan. Strategi umum termasuk versi URI (misalnya, /v1/users), menggunakan header permintaan khusus untuk versi, atau menggunakan versi tipe media (melalui header Accept). Setiap pendekatan memiliki serangkaian kerumitan dan kompromi sendiri.
  • HATEOAS Sering Diabaikan: Meskipun merupakan prinsip inti REST, HATEOAS sering kali tidak sepenuhnya diimplementasikan. Ini membatasi kemudahan penemuan sejati dan kemampuan berkembang dinamis yang ingin disediakan oleh REST.
  • Tidak Ada Pengetikan Kuat di Luar Kotak: Tidak seperti sistem RPC yang menggunakan IDL, REST mengandalkan konvensi dan dokumentasi eksternal (seperti spesifikasi OpenAPI/Swagger) untuk mendefinisikan kontrak API. Ini tidak selalu diberlakukan pada waktu kompilasi, yang berpotensi menyebabkan masalah integrasi.

Kapan Menggunakan REST:

REST adalah pilihan yang sangat baik untuk API yang menghadap publik di mana adopsi luas, kemudahan integrasi, dan interoperabilitas adalah hal penting. Ini cocok untuk aplikasi yang berpusat pada sumber daya di mana operasi CRUD (Create, Read, Update, Delete) standar pada entitas membentuk mode interaksi utama. Jika memanfaatkan caching HTTP sangat penting untuk kinerja dan skalabilitas, keselarasan REST dengan standar HTTP adalah keuntungan yang signifikan. Situasi yang menuntut statelessness dan skalabilitas horizontal juga sangat diuntungkan dari gaya arsitektur RESTful. Selain itu, ketika kemudahan penemuan melalui hypermedia (HATEOAS) diinginkan untuk memungkinkan klien menavigasi API secara dinamis, REST menyediakan framework untuk itu.

GraphQL: Bahasa Kueri untuk API Anda

Apa itu GraphQL?

GraphQL adalah bahasa kueri yang dirancang khusus untuk API, dan juga mencakup runtime sisi server untuk mengeksekusi kueri ini menggunakan sistem tipe yang Anda definisikan untuk data Anda. Awalnya dikembangkan oleh Facebook dan kemudian di-open source pada tahun 2015, GraphQL dikonsep untuk secara langsung mengatasi beberapa keterbatasan inheren yang diamati dalam arsitektur RESTful, terutama masalah kembar over-fetching dan under-fetching data. Ini memberdayakan klien untuk meminta data persis yang mereka butuhkan, tidak lebih dan tidak kurang, biasanya dalam satu siklus permintaan-respons.

Konsep Inti GraphQL:

Arsitektur GraphQL dibangun di atas beberapa konsep fundamental.

Landasannya adalah Schema Definition Language (SDL). API GraphQL didefinisikan secara ketat oleh sistem tipe yang kuat. Server mempublikasikan skema yang secara cermat menjelaskan semua tipe data yang diizinkan klien untuk dikueri, serta hubungan rumit yang ada di antara tipe data ini. Skema ini berfungsi sebagai kontrak yang mengikat antara klien dan server. Di dalam SDL, Anda mendefinisikan berbagai konstruksi:

  • Types menjelaskan objek yang dapat Anda ambil dan field-fieldnya (misalnya, type User { id: ID!, name: String, email: String, posts: [Post] }).
  • Queries mendefinisikan titik masuk untuk operasi pengambilan data (misalnya, type Query { user(id: ID!): User, posts: [Post] }).
  • Mutations mendefinisikan titik masuk untuk operasi modifikasi data—membuat, memperbarui, atau menghapus data (misalnya, type Mutation { createUser(name: String!, email: String!): User }).
  • Subscriptions mendefinisikan bagaimana klien dapat menerima pembaruan real-time ketika data spesifik berubah di server (misalnya, type Subscription { newPost: Post }).

Fitur pembeda lainnya adalah penggunaan Single Endpoint yang khas. Berbeda dengan REST, yang umumnya menggunakan banyak URL untuk merepresentasikan sumber daya dan operasi yang berbeda, API GraphQL biasanya hanya mengekspos satu endpoint (misalnya, /graphql). Semua permintaan, baik itu kueri untuk mengambil data, mutasi untuk memodifikasi data, atau langganan untuk pembaruan real-time, diarahkan ke endpoint tunggal ini, umumnya melalui permintaan HTTP POST.

Inti dari kekuatan GraphQL adalah konsep Client-Specified Queries. Aplikasi klien membangun string kueri yang secara eksplisit menentukan data persis apa yang dibutuhkan. Ini dapat mencakup tidak hanya field pada objek utama tetapi juga field pada objek terkait, melintasi hubungan data yang kompleks. Server kemudian memproses kueri ini dan merespons dengan objek JSON yang strukturnya secara tepat mencerminkan struktur kueri yang dikirimkan oleh klien.

Cara Kerja GraphQL:

Interaksi dalam sistem GraphQL mengikuti alur yang terdefinisi dengan baik. Ini dimulai dengan Schema Definition, di mana server mendefinisikan kemampuan datanya menggunakan SDL GraphQL.

Selanjutnya, Client Query dibangun. Klien merumuskan string kueri GraphQL, merinci field data spesifik yang dibutuhkan. Contohnya:GraphQL

query GetUserDetails {
  user(id: "123") {
    id
    name
    email
    posts { # Fetch related posts
      title
      content
    }
  }
}

Kueri ini kemudian dikirim dalam Request to Server, biasanya sebagai payload JSON dalam permintaan HTTP POST, menargetkan endpoint GraphQL tunggal.

Setelah menerima permintaan, Server Processing dimulai. Ini melibatkan beberapa sub-langkah. Server pertama-tama Parses & Validates kueri yang masuk, memeriksa sintaksisnya dan memastikan sesuai dengan skema yang ditentukan. Jika valid, kueri beralih ke Execution. Server mengeksekusi kueri dengan memanggil fungsi "resolver". Setiap field yang didefinisikan dalam skema GraphQL didukung oleh fungsi resolver yang sesuai. Resolver adalah bagian kode yang bertanggung jawab untuk mengambil data untuk field spesifiknya. Resolver ini dapat mengambil data dari berbagai sumber, seperti database, API internal atau eksternal lainnya, atau bahkan data statis.

Akhirnya, server merumuskan dan mengirimkan Response to Client. Respons ini adalah objek JSON yang strukturnya mencerminkan bentuk kueri asli, hanya berisi data yang secara eksplisit diminta. Untuk contoh kueri di atas, responsnya mungkin terlihat seperti:JSON

{
  "data": {
    "user": {
      "id": "123",
      "name": "Alice Wonderland",
      "email": "alice@example.com",
      "posts": [
        {
          "title": "My First Post",
          "content": "Hello world!"
        },
        {
          "title": "GraphQL is Cool",
          "content": "Learning about GraphQL..."
        }
      ]
    }
  }
}

Keunggulan GraphQL:

  • Tidak Ada Over-fetching atau Under-fetching: Klien meminta data persis yang mereka butuhkan, menghasilkan transfer data yang sangat efisien dan mengurangi bandwidth yang terbuang.
  • Satu Permintaan untuk Banyak Sumber Daya: Data terkait, bahkan di seluruh sumber daya konseptual yang berbeda, dapat diambil dalam satu kueri, secara signifikan mengurangi jumlah perjalanan bolak-balik jaringan.
  • Skema Berjenis Kuat: Skema berfungsi sebagai kontrak yang jelas dan otoritatif antara klien dan server. Pengetikan yang kuat ini memungkinkan alat pengembang yang kuat, seperti auto-completion, analisis statis, dan validasi kueri, dan juga berfungsi sebagai bentuk dokumentasi diri.
  • Kemampuan Berkembang (Evolvability): Menjadi lebih mudah untuk mengembangkan API tanpa menggunakan versi. Menambahkan field atau tipe baru ke skema tidak merusak klien yang ada, karena mereka hanya menerima data yang secara eksplisit mereka minta. Mendeprekasi field lama juga lebih mudah.
  • Data Real-time dengan Subscriptions: GraphQL menyertakan dukungan bawaan untuk pembaruan real-time melalui subscriptions, memungkinkan klien untuk mendengarkan perubahan data spesifik di server.
  • Introspektif: API GraphQL bersifat introspektif secara alami. Klien dapat mengueri skema itu sendiri untuk menemukan tipe, field, kueri, mutasi, dan subscriptions yang tersedia, memfasilitasi eksplorasi dan pembuatan klien dinamis.

Kekurangan GraphQL:

  • Kompleksitas: Menyiapkan dan mengelola server GraphQL bisa lebih kompleks dibandingkan dengan API REST sederhana, terutama terkait implementasi logika resolver, desain skema, dan optimasi kinerja.
  • Caching: Mekanisme caching HTTP kurang mudah diterapkan langsung di GraphQL dibandingkan dengan caching berbasis sumber daya REST. Meskipun solusi caching sisi klien yang canggih (seperti Apollo Client atau Relay) ada, caching sisi server dan perantara memerlukan strategi yang berbeda, dan caching tingkat field bisa rumit.
  • Unggahan File: Spesifikasi GraphQL tidak secara native menangani unggahan file. Ini biasanya memerlukan solusi, seperti menggunakan endpoint REST terpisah untuk penanganan file atau mengimplementasikan library pemrosesan permintaan multipart bersama GraphQL.
  • Pembatasan Tingkat (Rate Limiting): Mengimplementasikan pembatasan tingkat yang efektif bisa lebih kompleks karena "biaya" atau intensitas sumber daya dari kueri GraphQL tidak langsung terlihat hanya dengan melihatnya; kueri yang bersarang dalam atau kompleks bisa sangat mahal untuk dieksekusi. Ini sering memerlukan mekanisme analisis biaya kueri.
  • Kurva Belajar: Ada kurva belajar yang terkait dengan pemahaman konsep GraphQL, menguasai praktik terbaik desain skema, dan menjadi mahir dalam bahasa kueri itu sendiri.
  • Perangkap Kinerja: Resolver yang ditulis dengan buruk atau kueri yang terlalu kompleks dan bersarang dalam dapat menyebabkan masalah kinerja, seperti masalah N+1 (di mana mengambil daftar item dan anak-anaknya menghasilkan satu kueri untuk daftar dan N kueri tambahan untuk anak-anak setiap item), jika tidak ditangani dengan hati-hati menggunakan teknik seperti data loader.

Kapan Menggunakan GraphQL:

GraphQL sangat cocok untuk aplikasi dengan klien yang beragam, seperti aplikasi web, aplikasi seluler, dan perangkat IoT, yang semuanya mungkin memiliki kebutuhan data yang bervariasi dan spesifik. Ini unggul dalam situasi di mana meminimalkan transfer data dan mengurangi jumlah perjalanan bolak-balik jaringan sangat penting, misalnya, dalam aplikasi seluler yang beroperasi pada jaringan yang lambat atau tidak stabil. Untuk sistem yang kompleks di mana klien perlu mengambil data dari banyak sumber yang mendasarinya atau menavigasi hubungan sumber daya yang bersarang dalam, GraphQL menawarkan solusi yang elegan. Jika kontrak API yang berjenis kuat, kemampuan dokumentasi diri yang kuat, dan kemampuan berkembang API sangat dihargai, GraphQL menyediakan manfaat ini. Aplikasi yang memerlukan pembaruan real-time melalui subscriptions dapat memanfaatkan dukungan native GraphQL untuk fitur ini. Pada akhirnya, GraphQL adalah pilihan yang sangat baik ketika Anda ingin memberikan lebih banyak kekuatan dan fleksibilitas kepada klien dalam cara mereka mengambil data, menyesuaikan permintaan dengan kebutuhan spesifik mereka.

RPC vs. REST vs. GraphQL: Pandangan Komparatif

FiturRPC (misalnya, gRPC)RESTGraphQL
ParadigmaBerorientasi tindakan/fungsiBerorientasi sumber dayaBahasa kueri data
EndpointBeberapa endpoint (satu per prosedur)Beberapa endpoint (satu per sumber daya/koleksi)Biasanya satu endpoint (/graphql)
Pengambilan DataServer mendikte data yang dikembalikan per prosedurServer mendikte data yang dikembalikan per sumber dayaKlien mendikte data persis yang dibutuhkan
Over/Under FetchingRentan terhadap keduanya, berdasarkan desain prosedurMasalah umum (over-fetching/under-fetching)Mengatasi over/under-fetching
Penggunaan HTTPDapat menggunakan HTTP/2 (gRPC), atau transport lainSangat mengandalkan metode HTTP, kode statusBiasanya menggunakan HTTP POST, satu endpoint