Dari Kebingungan ke Pemahaman: Kisah Saya Membangun Microservice Pertama dengan RabbitMQ

Hari ini, saya memutuskan untuk membangun sebuah sistem microservice. Ya, microservice kata yang sering saya dengar di dunia development, tapi belum pernah benar-benar saya praktikkan. "Ini saatnya!" pikir saya, sambil menyeruput kopi yang sudah dingin karena terlalu lama menatap layar.

Awal Mula: RESTful API yang Kesepian

Semuanya dimulai dengan RESTful API. API ini adalah teman setia saya selama ini. Ia selalu siap melayani request dari client, memberikan response yang tepat, dan kadang-kadang mengeluh lewat error 500 ketika saya lupa handle exception. Tapi, semakin lama, saya merasa API ini kesepian. Ia harus menangani terlalu banyak tugas: validasi data, logika bisnis, bahkan ngurus database. "Kasihan sekali," pikir saya. "Ia butuh teman."

Lalu, saya punya ide: kenapa tidak memecah tugas-tugas ini ke dalam microservice? Tapi, bagaimana caranya microservice-microservice ini bisa berkomunikasi? Apakah mereka akan saling telepon? Atau kirim surat? Ternyata, jawabannya adalah RabbitMQ. RabbitMQ adalah sebuah message broker yang akan menjadi "kurir" bagi microservice-microservice saya.

RabbitMQ: Sang Kurir yang Setia

RabbitMQ ini seperti kurir pengiriman paket. Ia tidak peduli isi paketnya apa. Bisa data user, notifikasi, atau bahkan pesan error. Tugasnya hanya satu: mengantarkan pesan dari satu service ke service lain. "Simple, ya?" pikir saya. Tapi, seperti kurir pada umumnya, RabbitMQ punya aturan mainnya sendiri.

Pertama, saya harus membuat queue. Seperti kotak surat tempat pesan akan disimpan. Lalu, ada producer yang bertugas mengirim pesan ke queue, dan consumer yang akan mengambil pesan dari queue dan memprosesnya. "Ah, mirip seperti sistem pengiriman paket online," pikir saya. Producer itu seperti penjual, consumer seperti pembeli, dan queue adalah gudang penyimpanan.

Microservice Pertama: Auth Service

Saya memulai dengan membuat Auth Service. Sebuah microservice yang bertugas menangani autentikasi dan registrasi user. Service ini akan menerima request dari RESTful API, memprosesnya, dan mengirimkan pesan ke RabbitMQ jika ada data yang perlu diproses oleh service lain.

Contohnya, ketika seorang user mendaftar, Auth Service akan menyimpan data user ke database dan mengirimkan pesan ke queue registered-epg (singkatan dari "registered event processing gateway" saya suka memberi nama yang keren). Pesan ini berisi data user yang baru saja terdaftar.

await rabbitMQService.sendToQueue('registered-epg', JSON.stringify(userData));

"Gampang, kan?" pikir saya. Tapi, ternyata tidak semudah itu. Saya lupa bahwa consumer juga harus siap menerima pesan ini. Jadi, saya pun membuat User Service. sebuah microservice lain yang akan memproses pesan dari queue registered-epg.

User Service: Si Pekerja Keras

User Service ini seperti pekerja keras. Ia selalu standby, menunggu pesan dari RabbitMQ. Ketika pesan datang, ia akan memprosesnya. Misalnya, mengirim email selamat datang ke user atau menyimpan data tambahan ke database.

rabbitMQService.consumeQueue('registered-epg', async (message) => {
    const userData = JSON.parse(message);
    await userService.processUserRegistration(userData);
});

Tapi, ada satu masalah: bagaimana jika User Service down? Tenang, RabbitMQ punya solusinya. Pesan akan tetap disimpan di queue sampai ada consumer yang siap memprosesnya. "RabbitMQ ini benar-benar kurir yang bisa diandalkan," pikir saya.

RESTful API: Si Penghubung

RESTful API saya sekarang punya peran baru: sebagai penghubung antara client dan microservice. Ia tidak lagi kesepian karena sekarang punya teman-teman microservice yang siap membantunya. Misalnya, ketika client mengirim request untuk login, API akan memanggil Auth Service untuk memverifikasi email dan password.

const auth = await authService.login(email, password);
if (!auth) {
    return res.status(401).json({ error: 'Invalid credentials' });
}

Jika login berhasil, API akan mengembalikan token ke client. "Sekarang, API ini seperti manajer proyek yang handal," pikir saya. Ia tahu kapan harus mendelegasikan tugas ke microservice lain.

Masalah yang Muncul: Error Handling

Tentu saja, tidak semua berjalan mulus. Suatu hari, saya menemukan error aneh: "token cannot be an array or an object". Setelah menelusuri kode, saya sadar bahwa saya lupa menggunakan await saat memanggil fungsi asynchronous. Akibatnya, yang dikirim ke RabbitMQ adalah Promise, bukan nilai sebenarnya.

"Ah, dasar saya!" pikir saya, sambil memperbaiki kode:

const accessToken = await generateAccessToken(user); // Jangan lupa await!

Setelah itu, semuanya berjalan lancar. "Belajar dari kesalahan adalah bagian dari proses," pikir saya, sambil menambahkan catatan di buku harian: "Selalu gunakan await saat memanggil fungsi asynchronous!"

Kesimpulan: Sistem yang Harmonis

Setelah melalui berbagai tantangan, akhirnya sistem microservice saya berjalan dengan baik. RESTful API tidak lagi kesepian, RabbitMQ menjadi kurir yang andal, dan microservice-microservice saling bekerja sama dengan harmonis.

Saya pun merasa bangga. "Ini baru awal," pikir saya. Masih banyak hal yang harus dipelajari: scaling, monitoring, dan lain-lain. Tapi, untuk saat ini, saya puas dengan hasil yang sudah dicapai.

Sambil menutup laptop, saya tersenyum. "Mungkin besok saya akan menambahkan fitur notifikasi. Atau, siapa tahu, integrasi dengan service lain. Tapi, sekarang, waktunya istirahat. Selamat malam, dunia development!"

Refleksi

Membangun sistem microservice dengan RabbitMQ dan RESTful API memang seperti petualangan. Ada tantangan, ada kesalahan, tapi juga ada kepuasan ketika semuanya berjalan dengan baik. Yang penting adalah terus belajar dan tidak takut mencoba hal baru. Siapa tahu, suatu hari nanti, sistem yang kita bangun akan menjadi fondasi bagi sesuatu yang lebih besar.

Selamat mencoba, dan semoga petualangan Anda menyenangkan! 😊