Architecture | Sprint last?.02.05.19 — Asel H.S.
Halo! Kembali lagi bersama saya, Hacker Praying Mantissa! Kali ini saya ingin menceritakan bagaimana arsitektur dari produk kami, Blood in Time.
Untuk memberikan konteks, produk kami adalah android app yang memiliki fitur untuk membuat event yang berkaitan dengan donor darah. Setiap event yang ada nantinya harus diverifikasi oleh admin dari produk yang dibuat tim A8, yaitu rationnarium. Lalu bagaimana arsitektur dibalik BIT?
Android dengan Backend
Karena produk kami berbasis online, kami harus memiliki tempat penyimpanan data yang ada dan bisa diakses melalui internet. Oleh karena itu, kami membuat service backend sebagai solusi dari permasalahan kami. Kami mengikuti konvensi REST API pada untuk mengakses backend karena endpoint memiliki abstraksi yang jelas. Pada android app-nya kami mengikuti MVC design pattern, dengan Controller yang memanggil endpoint yang ada pada backend kami.
Backend
Feature-wise aplikasi kami tidaklah kompleks, mayoritas dari fitur yang kami buat hanyalah proses CRUD yang simpel. Untuk menunjang itu, kami menggunakan PostgreSQL sebagai data persistence. Seles-
Eits, tidak semudah itu fergusso. Product owner meminta fitur-fitur yang lain.
Enter Asynchronous Job
Users hate loading. Oleh karena itu tidak mungkin kita nyelipin proses yang lama (ngirim email, buat notifikasi, nungguin ratio bales, etc etc) di proses request-response. Solusinya? selipin aja proses yang bentar.
Saya mengambil solusi untuk jalanin async job biar service lain aja yang ngerjain, service backend tetep bisa ngelayanin android app tanpa harus nunggu proses tersebut. Selain itu, dengan async job kita bisa implementasi rule prioritas job (sinkronisasi dengan ratio lebih penting dari ngirim email welcome ke user baru), memastikan job yang dikerjakan pasti akan berhasil (in case 3rd party service mati), dan mengatur behaviour dari job retry (seberapa lama harus retry, implementasi exponential backoff, etc etc).
Untuk implementasinya, saya memilih celery sebagai kuli async job (Worker) dan rabbitmq sebagai penyedia kerjaan (Message broker).
Cara penggunaannya juga mudah karena hanya menggunakan library yang sudah ada. Untuk membuat job baru tinggal membuat function dengan decorator @shared_task dan untuk menjalankan tinggal <nama_fungsi>.delay(<parameter>).
Terus apa aja sih yang make async job?
Notification (Firebase)
Yang pertama adalah notification. Kami menggunakan firebase messaging cloud sebagai pembantu untuk menghasilkan notifikasi. Kenapa harus di-async?
- Firebase, walaupun punya google, bisa aja mati. Walaupun mati notif yang ada tetep harus kekirim setelah firebasenya nyala lagi.
- Exponential backoff. Google secara eksplisit mengharuskan melakukan exponential backoff untuk mencoba ulang request. Dengan celery, job bisa diimplementasi agar melakukan hal tersebut.
- Scheduled notification. Yang sejauh saya baca, firebase hanya mensupport instant notification, notifikasi langsung terbentuk ketika kami memanggil API-nya. Sementara kami memerlukan notifikasi yang di-delay pada aplikasi kami. Dengan adanya async job, kami bisa membuat job yang di-delay waktu kerjanya sehingga “delayed notification” dapat tercapai.
Sinkronisasi data (Rationnarium)
Rationnarium secara garis besar adalah tampilan antarmuka untuk admin yang berasal dari PMI. Oleh karena itu, kedua backend kami haruslah bisa berkomunikasi satu sama lain. Setelah melewati kompromi yang panjang, disepakati bahwa kami saling menyediakan endpoint via REST API.
Untuk data yang diperlukan dari mereka dan diperlukan di Android, kami cukup dengan membuat request ke server mereka langsung. Sayangnya kasus di backend tidak semudah itu.
Karena kami memiliki redundansi data di masing-masing service kami, kami harus memastikan bahwa data pada kedua tempat tersebut konsisten. Proses sinkronisasi tersebut cocok dimasukkan ke asynchronous job karena :
- User tidak harus menunggu sinkronisasi data; yang penting ketika data sudah ada di service kami, user sudah bisa lega (?).
- Unreliable connection. Kami mengandalkan internet sebagai jembatan antar service kami. Oleh karena itu kami harus memastikan setidaknya sinkronisasi tersebut berhasil, walaupun jika ratio tidak bisa akses.
2 Mei 2019 : Saya ingin menunjukkan implementasi, sayangnya masih WIP. Ketika sudah selesai nanti saya update lagi.
Email (SMTP)
Yang ini ngirim email verifikasi dan selamat datang. Alasannya async kurang lebih sama seperti alasan alasan sebelumnya.
Sekian pengalaman dari saya, sampai jumpa!
—
Asel Hidayat Sjamhars
02.05.2019