Belajar Backend Developer - API Gateway & gRPC

#Pendahuluan

Saat sistem kalian tumbuh — apalagi setelah episode 12 memisahkan layanan — muncul kebutuhan baru: bagaimana mengatur semua pintu masuk? Di monolith, satu aplikasi menangani routing dan auth. Di sistem terdistribusi, ratusan endpoint tersebar di banyak service; memeriksa auth, rate limit, dan versioning di tiap service berarti duplikasi di mana-mana.

Solusinya dua lapis: API gateway sebagai pintu masuk terpusat untuk client, dan gRPC sebagai jalan raya antar service yang lebih efisien daripada HTTP/JSON. Episode ini membahas keduanya — kenapa dibutuhkan, kapan dipakai, dan bagaimana menyetelnya.

#API Gateway

API gateway adalah satu titik masuk untuk semua client, yang meneruskan request ke service yang tepat. Ia mengambil alih tugas lintas-potong agar tidak diulang di tiap service.

#Tugas Utama Gateway

Keuntungan terbesarnya: kebijakan diubah satu tempat, tidak di tiap service. Menambah rate limit global cukup di gateway, bukan di 5 service.

#Contoh: Kong

Salah satu gateway populer adalah Kong — open source, plugin-based:

docker run -d --name kong-lab \
  -e KONG_DATABASE=off \
  -e KONG_PROXY_ACCESS_LOG=/dev/stdout \
  -p 8000:8000 \
  kong/kong-gateway:latest

curl -s -X POST http://localhost:8001/services \
  -d "name=catalog" -d "url=http://catalog-svc:3000"
curl -s -X POST http://localhost:8001/services/catalog/routes \
  -d "paths[]=/v1/products"

Sekarang GET http://localhost:8000/v1/products diteruskan ke catalog service — dan kalian bisa menempelkan plugin auth/rate-limit ke route tersebut tanpa menyentuh kode service.

#Kapan Tidak Perlu Gateway

Jangan pasang gateway karena terlihat modern. Untuk monolith atau modular monolith, gateway adalah lapisan ekstra tanpa manfaat — aplikasi sudah jadi pintu masuknya sendiri. Gateway mulai masuk akal saat:

• Ada beberapa service yang harus dibatasi rate limit-nya secara terpusat.
• Client yang beragam (web, mobile, partner) butuh titik masuk berbeda.
• Kebijakan (auth, versioning, observability) perlu diubah tanpa deploy service.

#gRPC: Komunikasi Service-to-Service

HTTP/JSON untuk service-to-service memakai parsing text yang boros. Untuk percakapan antar service yang berulang dan intensif (ratusan ribu panggilan/detik), gRPC jauh lebih efisien:

• Protobuf — data serialisasi biner, jauh lebih kecil dan cepat diparsing daripada JSON.
• HTTP/2 — multiplexing, compression header, bi-directional streaming.
• Kontrak wajib — skema .proto didukung tooling dan codegen di semua bahasa.

#Definisi Kontrak

syntax = "proto3";
 
package catalog;
 
service CatalogService {
  rpc GetProduct(GetProductRequest) returns (Product);
  rpc ListProducts(ListRequest) returns (ListResponse);
}
 
message GetProductRequest {
  int64 id = 1;
}
 
message Product {
  int64 id = 1;
  string name = 2;
  double price = 3;
  int32 stock = 4;
}
 
message ListRequest {
  int32 limit = 1;
}
 
message ListResponse {
  repeated Product products = 1;
}

#Server dan Client

import { createServer } from "connectrpc"
 
const server = createServer({
  services: [CatalogService],
  handlers: {
    [CatalogService.method.getProduct]: async (req) => {
      const { rows } = await db.query(
        "SELECT * FROM products WHERE id = $1",
        [req.id],
      )
      return { ...rows[0] }
    },
  },
})
 
server.listen(50051)

import { createClient } from "connectrpc"
import { CatalogService } from "./gen/catalog_pb.js"
 
const client = createClient(CatalogService, baseUrl, {
  transport: createConnectTransport({ baseUrl: "http://catalog:50051" }),
})
 
const product = await client.getProduct({ id: 42 })

#HTTP/JSON vs gRPC: Kapan Memakai Mana

Aturan praktis: untuk API publik yang dipakai browser/mobile → REST/HTTP. Untuk percakapan antar service internal → gRPC. Tidak harus memilih satu — sistem sehat memakai keduanya: REST di tepi, gRPC di dalam.

#Praktik: Set Up Gateway untuk Toko Online

Alur untuk sistem kita (macrolith, episode 12):

1. Gateway (nginx/Kong) sebagai satu pintu: /v1/products → catalog, /v1/orders → order.
2. Auth & rate limit di gateway: verifikasi JWT (episode 7) dan batas 100 req/menit per client.
3. gRPC untuk percakapan internal: order service memanggil catalog service untuk cek harga/stok via gRPC, bukan HTTP.
4. REST tetap untuk client publik.

upstream catalog_upstream { server catalog-svc:3000; }
upstream order_upstream { server order-svc:3001; }
 
server {
    listen 80;
 
    location /v1/products {
        proxy_pass http://catalog_upstream;
    }
 
    location /v1/orders {
        proxy_pass http://order_upstream;
    }
}

#Common Pitfalls

#Gateway Jadi Single Point of Failure

Semua request lewat gateway — jika mati, semua mati. Jalankan lebih dari satu instance di belakang load balancer (episode 21) dan pantau kesehatannya.

#REST Digunakan untuk Internal

HTTP/JSON antar service dengan traffic tinggi boros bandwidth dan CPU. Ukur; jika internal traffic dominan, pindahkan ke gRPC.

#Kontrak Tanpa Skema

Internal service yang bicara REST tanpa skema rawan rusak diam-diam. Jika memakai REST internal, setidaknya terapkan OpenAPI + contract test.

#Duplikasi Kebijakan

Auth dan rate limit di tiap service = tidak konsisten dan susah dirawat. Pindahkan ke gateway atau library bersama — pilih salah satu, jangan keduanya.

#Penutup

Episode 13 menyatukan gerbang sistem: API gateway untuk routing, auth, rate limit, dan observability terpusat; gRPC dengan protobuf untuk komunikasi internal yang efisien; plus aturan memakai REST di tepi dan gRPC di dalam.

Inti yang harus dibawa pulang:

• Gateway = satu titik masuk; kebijakan diubah satu tempat.
• Jangan pasang gateway untuk monolith — itu lapisan ekstra tanpa manfaat.
• gRPC: biner, cepat, kontrak wajib — untuk service-to-service.
• REST untuk client publik; gRPC untuk internal; boleh memakai keduanya.
• Gateway harus ber-replica dan terpantau — jangan jadi titik kegagalan tunggal.

Di episode 14 selanjutnya kita akan mengemas service menjadi artefak yang portable: container & dockerization — Dockerfile yang benar, optimasi image, dan docker-compose. Sampai jumpa di episode 14!