Mengapa Kami Beralih dari WebSocket ke REST API Smart Polling di Mobile Web

Di atas kertas, WebSocket selalu dianggap sebagai standar emas untuk komunikasi real-time pada aplikasi web modern. Protokol full-duplex TCP dua arah ini menjanjikan latensi minim dengan overhead header yang sangat ringan setelah proses handshake awal selesai.

Namun, ketika arsitektur tersebut diterapkan pada portal web yang diakses mayoritas pengguna melalui ponsel pintar (mobile browser), kenyataan di lapangan berkata lain. Koneksi WebSocket seringkali menjadi titik kerapuhan terbesar (single point of failure), menghasilkan banjir error reconnect di konsol pengguna dan pengalaman penautan JadiBot yang tersendat.

Berikut adalah catatan teknis mendalam mengapa kami memutuskan merombak seluruh layer komunikasi frontend di portal my.bochi.space dari WebSocket (WSS) murni menuju Smart Adaptive REST API Polling berbasis Redis Buffer.

Masalah Mendasar WebSocket di Browser Mobile

Browser ponsel (Safari di iOS maupun Chrome di Android) memiliki sistem manajemen daya yang sangat agresif. Ketika pengguna beralih tab, meminimalkan browser, atau membiarkan layar ponsel terkunci selama beberapa detik, thread JavaScript di browser langsung dibekukan (suspended).

Hal ini menimbulkan rentetan komplikasi: 1. Broken Heartbeat (Ping/Pong Drop): Ping WebSocket yang dijadwalkan setiap 25 detik terhenti secara sepihak oleh sistem operasi ponsel. Server menganggap klien sudah mati dan memutus koneksi (TCP RST). 2. Zombie Sockets di Server: Ribuan koneksi socket lama tetap menggantung di kernel server sampai timeout sistem tercapai, menghabiskan alokasi file descriptor (ulimit). 3. Throttled Reconnection Storm: Begitu pengguna membuka kembali ponsel mereka, browser mencoba menyambung ulang serentak dalam hitungan milidetik, menciptakan lonjakan trafik handshake HTTP upgrade yang membebani gateway.

Batasan Timeout 100 Detik Reverse Proxy & Cloudflare

Mayoritas infrastruktur web modern menggunakan Content Delivery Network (CDN) atau reverse proxy seperti Cloudflare Workers, AWS CloudFront, atau Nginx.

Cloudflare secara baku membatasi masa idle timeout koneksi WebSocket proxy publik menjadi maksimum 100 detik jika tidak ada payload data bolak-balik. Di portal JadiBot, saat bot WhatsApp sudah terhubung stabil dan tidak ada aktivitas chat selama beberapa menit, koneksi WebSocket yang sunyi tersebut otomatis diputus dengan kode status 1006 (Abnormal Closure).

Bagi pengguna awam, tulisan "Connection Closed 1006" di terminal konsol terlihat seperti bot mereka mati atau rusak, padahal engine Go di backend tetap berjalan normal 24/7. Mengirimkan paket ping periodik memang membantu, tetapi kembali memicu masalah konsumsi daya baterai di perangkat pengguna.

Arsitektur Smart Adaptive Polling Tiga Tingkat

Solusi paling elegan yang kami temukan adalah beralih ke paradigma Stateless REST API Polling dengan algoritma adaptif dinamis (Adaptive Interval). Daripada mempertahankan socket persisten yang rapuh, browser mengirimkan HTTP request singkat dengan interval yang menyesuaikan fase sesi bot:

// Cuplikan Logika Smart Adaptive Polling
const intervalMs = isPairingPhase 
  ? 2000    // Fast Auth: Interval cepat 2s saat menunggu kode pairing 8 digit / QR
  : isConnected
    ? 3000  // Terminal Stream: Interval 3s untuk streaming buffer log Redis
    : 5000; // Idle & Error Backoff: Melindungi server saat jaringan tidak stabil

Tiga fase interval tersebut bekerja secara presisi: - Fast-Auth Tier (2 Detik): Hanya aktif ketika pengguna memasukkan nomor telepon dan menunggu kode pairing 8 digit atau QR Code WhatsApp. Begitu token sesi disetujui, siklus langsung melambat. - Log Streaming Tier (3 Detik): Berjalan saat bot aktif untuk mengambil potongan log konsol terbaru tanpa menahan resource port terbuka. - Graceful Error Backoff (5 Detik): Jika terjadi gangguan jaringan, klien tidak memborbardir server, melainkan mundur teratur dan mencoba kembali secara halus.

Redis In-Memory Ring Buffer untuk Streaming Log

Tantangan terbesar menggantikan WebSocket adalah streaming teks konsol terminal. Bagaimana pengguna tetap bisa melihat log aktivitas bot baris demi baris secara lancar tanpa socket?

Kami mengimplementasikan struktur data Circular Ring Buffer menggunakan Redis List (RPUSH & LTRIM): 1. Setiap pesan log dari engine Go dimasukkan ke Redis key jadibot:terminal:. 2. Redis otomatis memotong buffer hanya menyimpan maksimum 300 baris terbaru, mencegah pembengkakan memori RAM server. 3. Endpoint REST GET /api/v1/jadibot/status mengembalikan snapshot log tersebut dalam format array JSON ringan dengan kompresi gzip.

Ketika browser memanggil endpoint setiap 3 detik, komponen terminal React hanya melakukan merge baris baru ke dalam layar virtual konsol. Pengguna mendapatkan ilusi streaming real-time yang sempurna, namun dengan keandalan protokol HTTP tanpa batas waktu koneksi.

Perbandingan Efisiensi Memori & Daya Baterai

Berikut perbandingan performa terukur setelah migrasi:

Kesimpulan & Rekomendasi Praktis

Jangan memilih WebSocket hanya karena terlihat modern atau keren di artikel arsitektur. Pilih protokol yang paling tangguh menghadapi realitas jaringan pengguna di dunia nyata.

Untuk portal dashboard pemantauan, otentikasi pairing perangkat, dan log konsol sesaat di browser mobile, Smart Adaptive REST API Polling terbukti jauh lebih stabil, tahan banting terhadap timeout proxy Cloudflare, dan bebas dari keluhan koneksi terputus.