Bagaimana Client dan Server Berkomunikasi di Sistem Modern?
5 min read Software Engineering

Bagaimana Client dan Server Berkomunikasi di Sistem Modern?

Artikel ini membahas berbagai jenis komunikasi antara client dan server yang paling banyak digunakan oleh backend engineer dan frontend engineer saat ini. Setiap jenis komunikasi akan dijelaskan dari tiga sudut pandang utama:

  1. Sejarah – bagaimana dan mengapa teknologi ini muncul
  2. Summary penggunaan – gambaran cara kerja dan pola pemakaian
  3. Penggunaan umum – contoh nyata pada aplikasi, arsitektur, dan ekosistem

REST (Representational State Transfer)

Sejarah

REST diperkenalkan oleh Roy Fielding pada tahun 2000 dalam disertasi doktornya. REST bukanlah protokol, melainkan arsitektur gaya (architectural style) yang memanfaatkan HTTP secara maksimal. REST lahir sebagai kritik terhadap sistem web yang terlalu kompleks seperti SOAP.

Summary Penggunaan

REST menggunakan:

  • HTTP methods: GET, POST, PUT, PATCH, DELETE
  • Resource berbasis URL (/users, /orders/123)
  • Stateless communication
  • Format data umum: JSON (sebelumnya XML)

Client dan server berkomunikasi melalui request–response standar HTTP.

Penggunaan Umum

  • Frontend (Web / Mobile) ke Backend API
  • Public API (payment, maps, auth)
  • Backend monolith
  • CRUD-based system

Contoh:

  • Web app → API server
  • Mobile app → Backend REST API

GraphQL

Sejarah

GraphQL dikembangkan oleh Facebook (Meta) pada tahun 2012 dan dirilis sebagai open-source pada 2015. GraphQL dibuat untuk mengatasi masalah over-fetching dan under-fetching pada REST, terutama di aplikasi mobile.

Summary Penggunaan

GraphQL menggunakan satu endpoint (/graphql) dan client menentukan sendiri data apa yang dibutuhkan melalui query.

Konsep utama:

  • Query
  • Mutation
  • Subscription
  • Strongly typed schema

Client memiliki kontrol penuh terhadap struktur response.

Penggunaan Umum

  • Frontend-heavy application
  • Mobile apps dengan bandwidth terbatas
  • Complex UI dengan banyak data relasi
  • BFF (Backend for Frontend)

Contoh:

  • React / Apollo Client → GraphQL API
  • Mobile app → GraphQL Gateway

gRPC

Sejarah

gRPC dikembangkan oleh Google dan open-source pada 2016. gRPC terinspirasi dari sistem RPC internal Google dan dibangun di atas HTTP/2 serta Protocol Buffers (Protobuf).

Summary Penggunaan

gRPC menggunakan pendekatan Remote Procedure Call (RPC):

  • Client memanggil fungsi di server seolah-olah fungsi lokal
  • Data dikodekan dalam format biner (Protobuf)
  • Mendukung streaming (unary, server, client, bidirectional)

Penggunaan Umum

  • Microservices internal
  • High performance system
  • Low-latency communication
  • Backend-to-backend

Contoh:

  • Service A → Service B
  • Internal microservice communication

WebSocket

Sejarah

WebSocket distandarisasi pada tahun 2011 (RFC 6455) untuk mengatasi keterbatasan HTTP yang bersifat request–response satu arah.

Summary Penggunaan

WebSocket membuka koneksi persistent (long-lived) antara client dan server:

  • Full-duplex communication
  • Server bisa push data ke client
  • Tidak perlu request ulang

Penggunaan Umum

  • Real-time application
  • Chat application
  • Live notification
  • Online game

Contoh:

  • Chat app
  • Dashboard real-time

Server-Sent Events (SSE)

Sejarah

SSE diperkenalkan sebagai bagian dari HTML5 untuk menyediakan komunikasi satu arah dari server ke client.

Summary Penggunaan

  • Koneksi HTTP yang tetap terbuka
  • Server hanya bisa push data ke client
  • Lebih sederhana dibanding WebSocket

Penggunaan Umum

  • Live notification
  • Real-time log streaming
  • Stock price update

Contoh:

  • Monitoring dashboard

Webhooks

Sejarah

Webhooks muncul sebagai pola integrasi antar sistem SaaS untuk menghindari polling berulang.

Summary Penggunaan

Webhooks pada dasarnya adalah HTTP callback:

  • Server A mengirim HTTP request ke Server B saat event terjadi
  • Biasanya menggunakan POST

Penggunaan Umum

  • Third-party integration
  • Event-driven system
  • Payment notification

Contoh:

  • Payment gateway → App server
  • GitHub → CI/CD system

Message Queue / Event Streaming

Sejarah

Konsep message queue telah ada sejak sistem enterprise awal (IBM MQ). Modern implementations mencakup Kafka, RabbitMQ, SQS, Pub/Sub.

Summary Penggunaan

  • Asynchronous communication
  • Producer mengirim message
  • Consumer memproses message
  • Decoupling antar sistem

Penggunaan Umum

  • Event-driven architecture
  • Background processing
  • High-throughput system

Contoh:

  • Order service → Notification service

tRPC

Sejarah

tRPC muncul sekitar 2020-an seiring meningkatnya adopsi TypeScript dan kebutuhan end-to-end type safety.

Summary Penggunaan

  • RPC berbasis TypeScript
  • Tanpa schema terpisah (OpenAPI / GraphQL)
  • Type inference langsung dari backend ke frontend

Penggunaan Umum

  • Fullstack TypeScript
  • Internal product
  • Small to medium scale system

Contoh:

  • Next.js frontend → Node.js backend

Decision Guide: Memilih Jenis Komunikasi Client–Server

Section ini membantu engineer menentukan kapan menggunakan jenis komunikasi tertentu berdasarkan kebutuhan sistem.

Panduan Cepat (Rule of Thumb)

  • Gunakan REST jika:

    • Aplikasi CRUD standar
    • Public API
    • Tim besar dengan tooling beragam

  • Gunakan GraphQL jika:

    • Frontend membutuhkan fleksibilitas data
    • Banyak variasi UI dan relasi data kompleks
    • Menggunakan BFF pattern

  • Gunakan gRPC jika:

    • Komunikasi antar microservice
    • Butuh performa tinggi dan latency rendah
    • Lingkungan internal dan terkontrol

  • Gunakan WebSocket jika:

    • Real-time dua arah
    • Data sering berubah
    • Interaksi user intensif

  • Gunakan SSE jika:

    • Real-time satu arah
    • Implementasi ingin sederhana
    • Tidak perlu client → server push

  • Gunakan Webhook jika:

    • Integrasi antar sistem
    • Berbasis event
    • Menghindari polling

  • Gunakan Message Queue / Event Streaming jika:

    • Proses asynchronous
    • Decoupling antar service
    • High throughput dan reliability

  • Gunakan tRPC jika:

    • Fullstack TypeScript
    • Tim kecil–menengah
    • Fokus developer experience

Pertanyaan Kunci Sebelum Memilih

  • Apakah komunikasi perlu real-time?
  • Apakah client butuh kontrol penuh atas response?
  • Apakah sistem synchronous atau asynchronous?
  • Apakah komunikasi bersifat public atau internal?

Diagram Arsitektur per Jenis Komunikasi

Diagram berikut bersifat konseptual untuk membantu pemahaman alur komunikasi.

REST

Client → HTTP Request → API Server → HTTP Response → Client

Umumnya melalui:

  • Load Balancer
  • API Gateway

GraphQL

Client → GraphQL Query → GraphQL Server → Resolver → Data Source → Response

Satu endpoint melayani banyak kebutuhan frontend.

gRPC

Service A → Protobuf Request (HTTP/2) → Service B → Protobuf Response

Biasanya berada di dalam:

  • Private network
  • Service mesh

WebSocket

Client ⇄ Persistent Connection ⇄ Server

Data bisa dikirim kapan saja dari kedua sisi.

Server-Sent Events (SSE)

Client → HTTP Request → Server
Server → Stream Event → Client

Hanya server yang bisa push data.

Webhook

Event Occurs → Server A → HTTP POST → Server B

Server B menerima event secara pasif.

Message Queue / Event Streaming

Producer → Message Broker → Consumer

Komunikasi asynchronous dan terpisah secara logis.

tRPC

Frontend (TypeScript) → Typed RPC Call → Backend (TypeScript)

Type inference langsung tanpa schema tambahan.

Penutup

Tidak ada satu jenis komunikasi yang paling benar untuk semua kasus. Pemilihan metode komunikasi sangat bergantung pada:

  • Skala sistem
  • Kebutuhan real-time
  • Performance
  • Tim dan tooling

Backend dan frontend engineer yang baik memahami trade-off dari setiap pendekatan dan memilih sesuai konteks arsitektur.