Kodeloka📌 Masalah yang Diselesaikan
Tanpa gateway, setiap layanan harus menangani sendiri hal-hal yang sebenarnya sama: memverifikasi token, membatasi laju permintaan, mencatat log akses, menangani CORS, dan memasang TLS. Bila layanan Anda ditulis dalam tiga bahasa berbeda, logika itu ditulis ulang tiga kali dengan perilaku yang tidak pernah persis sama.
TANPA gateway DENGAN gateway
Klien Klien
├──> Layanan A (auth+limit) │
├──> Layanan B (auth+limit) ▼
└──> Layanan C (auth+limit) Kong (auth + rate limit + log + TLS)
├──> Layanan A (hanya logika bisnis)
Logika sama ditulis 3x ├──> Layanan B
di 3 bahasa berbeda └──> Layanan C⚙️ Kong Dibangun di Atas Apa
Kong bukan proxy yang ditulis dari nol. Ia adalah Nginx yang diperluas dengan OpenResty, sebuah bundel yang menyematkan penerjemah LuaJIT ke dalam Nginx. Setiap plugin Kong pada dasarnya adalah kode Lua yang dijalankan pada fase tertentu saat permintaan diproses.
Karena berbasis Nginx, Kong mewarisi karakter kinerjanya: sangat efisien untuk proxy HTTP, memakai model event non-blocking, dan penyetelan seperti jumlah worker atau ukuran buffer mengikuti aturan Nginx. Ketika menelusuri masalah kinerja, pengetahuan Nginx Anda tetap berlaku.
🧭 Ragam Kong yang Sering Membingungkan
| Nama | Apa itu |
|---|---|
| Kong Gateway (OSS) | Inti open source — proxy, routing, plugin dasar |
| Kong Gateway Enterprise | Tambahan berbayar: RBAC, Dev Portal, plugin lanjutan |
| Kong Konnect | Control plane terkelola di cloud; data plane tetap di infrastruktur Anda |
| Kong Ingress Controller | Menjalankan Kong sebagai ingress di Kubernetes |
| Kong Mesh | Service mesh berbasis Kuma — produk terpisah, bukan gateway |
Materi yang tampak membahas "Kong" sering sebenarnya mendemokan Konnect (produk SaaS berbayar) atau Kong Mesh (service mesh). Perhatikan baik-baik varian mana yang sedang dibahas sebelum mengikuti langkah-langkahnya — perintah dan konsepnya berbeda.
🚦 Kapan Gateway Belum Diperlukan
Seluruh trafik Anda kini melewati satu komponen tambahan yang harus dipantau, di-upgrade, dan dibuat redundan. Untuk aplikasi dengan satu atau dua layanan, reverse proxy sederhana atau bahkan ingress bawaan sudah cukup.
Gateway mulai sepadan ketika: ada banyak layanan yang butuh kebijakan seragam, Anda memublikasikan API ke pihak luar dan perlu kuota per konsumen, ada kebutuhan audit terpusat, atau layanan ditulis dalam banyak bahasa sehingga menegakkan kebijakan di kode menjadi mahal.