Belajar RabbitMQ - Multi-Protocol Support (MQTT, STOMP, WebSockets)

#Pendahuluan

Semua yang kita lakukan sejauh ini berjalan di atas protokol AMQP. Tapi tidak semua client bisa (atau mau) berbicara AMQP. Sensor IoT hanya memahami MQTT — protokol ringan untuk perangkat terbatas. Aplikasi web sering memakai STOMP atau WebSockets untuk push real-time. Memaksa semuanya memakai AMQP adalah kerja ekstra yang tidak perlu.

Jawaban RabbitMQ adalah plugin multi-protocol: broker yang sama, satu AMQP core, tapi pintu masuk berbeda-beda. MQTT, STOMP, dan WebSockets semuanya diterjemahkan ke model AMQP internal — topik, queue, dan exchange yang sama bisa diakses dari protokol mana pun.

Episode ini mengaktifkan dan mengonfigurasi ketiga protokol tersebut, memahami pemetaan antar protokol, serta melihat pola penggunaan nyata: dari dashboard IoT sampai chat real-time di browser.

#MQTT Plugin

#Mengaktifkan MQTT

Plugin MQTT menyediakan listener di port 1883 (dan 8883 untuk TLS):

rabbitmq-plugins enable rabbitmq_mqtt

Setelah aktif, client MQTT mana pun (misalnya mosquitto_pub) langsung terhubung:

mosquitto_pub -h localhost -t 'sensor/suhu' -m '{"suhu":29.5}'

Perintah mosquitto_pub mem-publish pesan ke topik MQTT sensor/suhu.

#Translasi MQTT ke AMQP

Setiap topik MQTT dipetakan ke exchange AMQP internal: topic sensor/suhu menjadi routing key sensor.suhu pada exchange amq.topic. Dengan begitu, consumer AMQP bisa menerima pesan MQTT dan sebaliknya — keduanya bertemu di exchange amq.topic.

#Pemetaan QoS Level

QoS MQTT dipetakan ke mekanisme AMQP:

• QoS 0 — best effort; dipetakan ke delivery transient tanpa confirms.
• QoS 1 — at-least-once; dipetakan ke ack manual dengan retry.
• QoS 2 — exactly-once; RabbitMQ memetakannya dengan sinkronisasi khusus.

Pemetaan ini penting saat mendesain perangkat: QoS 2 menelan biaya round-trip paling besar, jadi untuk perangkat dengan baterai terbatas sebaiknya pakai QoS 0 atau 1 sesuai kebutuhan aplikasi. Semakin tinggi QoS, semakin besar overhead komunikasi per pesan.

Use case terbesar MQTT adalah IoT: sensor berkemampuan terbatas yang mengirim telemetri dengan bandwidth kecil. Karena terjemahan dua arah, data sensor bisa langsung dikonsumsi pipeline AMQP di sisi backend.

#MQTT over WebSockets

Untuk browser yang perlu menerima topik MQTT, plugin juga menyediakan MQTT over WebSockets di port 15675 (/ws). Ini memungkinkan dashboard web memakai pustaka MQTT.js tanpa perubahan protokol.

#Mengonfigurasi Vhost dan User Default

Setiap plugin protokol punya user dan vhost default. Untuk MQTT, defaultnya guest dan vhost / — rentan jika node bisa diakses publik. Ganti dengan user dan vhost khusus:

mqtt.default_user = mqtt_svc
mqtt.default_pass = changeme
mqtt.default_vhost = /iot

Konfigurasi mqtt.default_vhost mengarahkan semua client MQTT yang tidak menentukan vhost ke /iot. Pola yang sama tersedia untuk STOMP (stomp.default_user, stomp.default_vhost) dan Web-STOMP (web_stomp.default_user). Dengan cara ini kalian bisa memisahkan trafik tiap protokol ke vhost berbeda.

#STOMP Plugin

#Mengaktifkan STOMP

STOMP adalah protokol tekstual sederhana yang populer untuk web messaging:

rabbitmq-plugins enable rabbitmq_stomp

STOMP mendengarkan di port 61613. Client mengirim frame SEND dan SUBSCRIBE yang dipetakan ke exchange dan queue AMQP: destination /topic/berita menjadi routing key pada exchange amq.topic, dan /queue/tugas menjadi queue dengan nama tugas.

#Web Messaging dan Browser

STOMP sangat populer untuk aplikasi web karena formatnya yang tekstual dan sederhana. Untuk browser, gunakan STOMP.js bersama WebSockets agar pesan real-time bisa diterima langsung di halaman web.

#WebSockets dan Web-STOMP

#Web-STOMP Plugin

Plugin rabbitmq_web_stomp menjembatani browser dan RabbitMQ: browser membuka WebSocket, lalu berbicara STOMP di dalamnya:

rabbitmq-plugins enable rabbitmq_web_stomp

Web-STOMP mendengarkan di port 15674 (/ws). Browser memakai STOMP.js untuk subscribe ke destination AMQP — ideal untuk notifikasi real-time seperti status pesanan atau live score.

#SockJS Integration

Untuk lingkungan dengan proxy yang tidak mendukung WebSocket penuh, gunakan SockJS: plugin rabbitmq_web_stomp mendukung fallback SockJS sehingga koneksi tetap bekerja melalui HTTP long-polling saat WebSocket diblokir. Konsumen cukup memilih transport yang tersedia otomatis.

#Memilih Protokol untuk Browser

Untuk aplikasi web, pilihan protokol bergantung pada kebutuhan: Web-STOMP paling umum karena STOMP sederhana dan dipetakan langsung ke model AMQP; MQTT over WebSockets cocok jika kalian sudah punya pipeline MQTT dan ingin dashboard menerima topik yang sama; raw WebSocket dengan AMQP tidak praktis karena AMQP adalah protokol binary yang rumit ditangani browser. Mulailah dengan Web-STOMP, lalu sesuaikan jika arsitektur menuntut protokol lain.

#Skenario End-to-End: Dashboard IoT

Semua protokol bisa digabungkan dalam satu alur nyata: sensor mem-publish telemetri lewat MQTT, dan dashboard browser menerimanya lewat Web-STOMP:

Sensor (MQTT, port 1883) ──► RabbitMQ (exchange amq.topic)
                                   │
                                   ▼
Dashboard browser (Web-STOMP, port 15674) ◄── subscribe /topic/telemetri

Sensor mem-publish ke topik telemetri, yang diterjemahkan menjadi routing key di exchange amq.topic. Dashboard browser subscribe ke destination /topic/telemetri lewat Web-STOMP, sehingga menerima data yang sama tanpa menulis satu baris pun di protokol AMQP. Satu broker, dua pintu masuk, satu aliran data.

#Penutup

Di episode 27 ini kalian sudah mengaktifkan plugin MQTT untuk IoT, STOMP untuk aplikasi web, dan WebSockets via Web-STOMP dan SockJS, memahami translasi protokol ke model AMQP, serta pemetaan QoS level MQTT.

Inti yang harus dibawa pulang:

• MQTT di port 1883; topik dipetakan ke exchange amq.topic.
• QoS MQTT dipetakan ke mekanisme ack AMQP.
• MQTT over WebSockets melayani dashboard IoT di browser.
• STOMP di port 61613 menggunakan frame tekstual SEND dan SUBSCRIBE.
• Web-STOMP di port 15674 menghubungkan browser via WebSocket.
• SockJS memberi fallback saat WebSocket tidak tersedia.
• Satu topik bertitik bisa diakses dari AMQP, MQTT, dan STOMP sekaligus.

Di episode 28 selanjutnya kita akan membahas client SDK best practices — pola connection recovery dan topology recovery, consumer cancellation notification, handling blocked connection, load balancing di sisi client, serta strategi error handling dengan retry logic dan circuit breaker untuk client Java, Python, Node.js, dan Go. Ini yang membuat aplikasi client tangguh!