Dari GetX ke Clean Architecture: Kenapa Kami Memigrasi Holigo per Fitur

Skala Bertambah, Batas Tercapai: Alasan Kuat Meninggalkan GetX

Holigo adalah aplikasi mobile multi-layanan yang menggabungkan banyak solusi transaksi dalam satu ekosistem: pembayaran tagihan, top-up digital, serta pemesanan tiket perjalanan mulai dari bus, kereta api, pesawat, hingga kapal laut.

Seiring bertambahnya variasi layanan dan volume transaksi, kami makin menyadari bahwa fondasi arsitektur aplikasi menentukan seberapa cepat dan aman tim bisa merilis fitur baru. Sebagai lead mobile developer di proyek ini, saya dihadapkan pada kenyataan bahwa arsitektur bawaan yang digunakan sebelumnya sudah mulai menunjukkan batas kemampuannya.

GetX memang terasa sangat praktis dan cepat di awal pengembangan. Namun untuk aplikasi skala besar dengan transaksi finansial aktif, kepraktisan itu harus dibayar mahal: reactivity otomatis GetX sering kali mem-bypass siklus hidup (lifecycle) standar Flutter, mutasi state sulit diprediksi, dan controller yang terikat erat ke UI membuat pengujian otomatis (unit & widget test) sangat sulit dieksekusi secara konsisten.

Menghindari Jebakan Rewrite: Memilih Strategi Migrasi Bertahap per Fitur

Ketika sebuah basis kode mulai terasa kusut, godaan terbesar bagi seorang engineer adalah melakukan "Big Bang Rewrite" — membuang seluruh kode lama dan menulis ulang aplikasi secara total dari nol.

Namun, menulis ulang seluruh aplikasi sekaligus adalah jebakan klasik rekayasa perangkat lunak: tim akan terjebak dalam masa vakum rilis berbulan-bulan tanpa memberikan value nyata ke pengguna, sementara risiko integrasi menumpuk dan baru meledak serentak saat hari peluncuran. Kami tidak bisa membiarkan operasional bisnis dan pendapatan perusahaan terganggu.

Karena itu, kami memilih pola migrasi bertahap (Strangler Fig pattern): aplikasi live GetX tetap berjalan melayani pengguna setiap hari, sementara fitur-fitur baru dibangun di atas fondasi Clean Architecture dan digantikan satu per satu. Pendekatan ini memecah risiko besar menjadi pecahan-pecahan kecil yang terkontrol, sehingga setiap modul bisa diuji, diverifikasi, dan dirilis mandiri ke store dengan aman.

Memilih Fitur Kapal (PELNI): Menjadikan Scope Terkecil Sebagai Blueprint

Pilihan fitur pertama memegang peranan krusial karena akan menentukan standar penulisan kode untuk seluruh fitur berikutnya. Dari berbagai layanan tiket yang tersedia di Holigo, kami secara sadar memilih tiket Kapal (PELNI) sebagai proyek percontohan (pilot project).

Kami memilih Kapal bukan karena fitur ini paling prestisius, melainkan karena cakupan fiturnya paling ringkas dan terisolasi dibanding pesawat atau kereta yang memiliki alur multi-passenger, bagasi, dan add-ons kompleks. Dengan scope yang terukur, tim bisa memusatkan seluruh energi untuk membentuk cetak biru (blueprint) arsitektur yang solid.

Di fitur Kapal inilah kami merumuskan standar pemisahan lapisan Presentation, Domain, dan Data, alur BLoC event-to-state yang deterministik, kontrak repository yang bersih, hingga standarisasi penanganan error jaringan. Ketika fitur pesawat dan kereta menyusul kemudian, polanya sudah teruji dan tim developer bisa langsung berfokus pada keunikan logika bisnis masing-masing fitur tanpa harus mendesain fondasi dari nol lagi.

Fondasi dan Trade-off: Menjaga Dua Sistem Hidup Berdampingan

Sebelum fitur pertama dipindahkan, bagian fondasi bersama di layer Core harus benar-benar matang terlebih dahulu. Kami menyiapkan router bridge untuk navigasi mulus lintas arsitektur, design system tokens, network client terpusat, dan dependency injection (DI) service locator yang kokoh.

Selama masa transisi, modul GetX lama dan modul Clean Architecture baru harus hidup berdampingan di satu aplikasi yang sama. Agar pengguna tidak merasakan kejanggalan visual maupun alur sesi, kami menyusun panduan migrasi yang ketat untuk state manajemen, standarisasi warna, font, padding, dan dialog konfirmasi di kedua belah pihak.

Tentu ada harga yang harus dibayar: Clean Architecture + BLoC menuntut lebih banyak file dan boilerplate untuk perubahan kecil dibanding kepraktisan GetX. Namun trade-off ini kami terima dengan senang hati, karena pemisahan tanggung jawab yang tegas antar lapisan serta tingginya kemampuan pengujian (testability) memberikan ketenangan pikiran dan kestabilan jangka panjang bagi tim.

Apa yang Bisa Dibawa dari Cerita Ini

Jika diringkas, ada beberapa pelajaran penting yang bisa dipakai kalau kamu sedang menghadapi situasi migrasi serupa:

Pilih fitur pertama yang kecil tapi representatif: Fitur pertama berfungsi sebagai contoh cetak biru bagi fitur-fitur berikutnya, sehingga cakupan yang ringkas membantu standarisasi pola arsitektur terbentuk jauh lebih cepat.

Tetapkan pola sebelum menambah fitur kedua: Konsistensi tim jauh lebih mudah dijaga ketika struktur lapisan kode, alur BLoC, dan penanganan error sudah disepakati bersama sejak awal.

Rawat konsistensi visual lewat panduan migrasi: Selama dua arsitektur hidup berdampingan, panduan bersama untuk state, warna, font, dan ukuran menjaga pengalaman pengguna tetap seragam tanpa friksi.

Jangan menunggu semua fitur selesai untuk mulai merilis: Rilis bertahap membuat risiko terbagi ke dalam unit-unit kecil, masalah di production terdeteksi lebih cepat, dan roda bisnis aplikasi tetap berjalan normal.

Penutup

Migrasi arsitektur pada dasarnya bukan sekadar mengganti library atau state management, melainkan menata ulang cara tim membangun, menguji, dan merawat produk dalam jangka panjang. Di Part 2 nanti, kita akan masuk lebih dalam ke struktur teknis lapisan presentation, domain, dan data dengan fitur Kapal sebagai contoh implementasi konkretnya.

Terima kasih telah membaca cerita saya :)

P.S. Seri ini ditulis di level keputusan dan arsitektur, tanpa membuka kode atau data internal perusahaan. Kalau ada pertanyaan, tanggapan, atau pengalaman migrasi serupa di tim mobile-mu, mari berdiskusi!