- Saat meluncurkan Dagger Cloud v3, UI baru ditulis dengan WebAssembly (WASM) dan Go
- Go umumnya tidak digunakan untuk pengembangan web UI, tetapi pendekatan ini dipilih demi "penyatuan codebase dan optimasi performa"
- Artikel ini membagikan "latar belakang keputusan, tantangan selama implementasi, dan hasil akhirnya"
Masalah sebelumnya: inefisiensi akibat dua codebase
- Dagger berjalan berbasis DAG (Directed Acyclic Graph), dan memvisualisasikannya melalui TUI (terminal UI) dan dashboard web (Dagger Cloud)
- Sebelumnya, TUI dibuat dengan Go, sedangkan web UI dibuat dengan React/TypeScript
- Namun sinkronisasi antara kedua UI sulit dilakukan, dan khususnya web UI mengalami masalah performa saat memproses data besar secara real-time
- Saat menangani event stream OpenTelemetry yang kompleks (ratusan ribu span), penurunan performa dan masalah kecepatan pada React UI menjadi sangat terlihat
- Fitur yang sama harus diimplementasikan dua kali, yang menjadi beban pengembangan besar bagi tim kecil
- Karena itu, mereka mempertimbangkan pendekatan baru dengan tujuan menyatukan codebase dan mengoptimalkan performa
Solusi yang dipilih: Go + WebAssembly
- Menyatukan codebase dengan Go
- Karena TUI sudah dibuat dengan Go, web UI juga bisa dibuat dengan Go agar kode dapat digunakan ulang
- Banyak pengembang Go di dalam tim, sehingga produktivitas tim meningkat dan maintenance menjadi lebih mudah
- Memanfaatkan WebAssembly (WASM)
- WebAssembly diadopsi agar kode Go bisa dijalankan langsung di browser
- Namun, ekosistem Go + WASM masih belum matang sehingga ada beberapa tantangan:
- Kekurangan library komponen → UI harus diimplementasikan sendiri
- Batas memori WASM di browser (2GB) → perlu optimasi saat menangani data besar
- Namun, optimasi memori ini juga bisa memberi manfaat untuk TUI maupun web UI
Strategi meminimalkan risiko proyek
- Menggunakan framework Go-app
- Memilih framework berbasis Go untuk pengembangan PWA (Progressive Web App)
- Menyediakan model berbasis komponen yang mirip React sehingga transisinya lebih mudah
- Membuat dan memverifikasi prototipe
- Mengimplementasikan ulang UI yang ada semaksimal mungkin dengan Go-app untuk mengidentifikasi isu utama
- WASM sendiri sudah merupakan standar terbuka yang terdokumentasi, dan sebagian besar pertanyaan utama dapat dijawab melalui dokumentasi Go-app
- Masalah terbesar adalah batas penggunaan memori, sehingga dibutuhkan desain dan optimasi untuk mengatasinya
Proses transisi dari prototipe ke production
Strategi optimasi performa
- Optimasi rendering log skala besar
- Perlu peningkatan performa rendering saat memproses data log lebih dari 200 ribu baris
- Untuk itu, mereka mengoptimalkan library rendering virtual terminal (midterm),
→ meningkatkan performa TUI maupun web UI
- Meningkatkan kecepatan parsing JSON
- Go WASM lambat dalam parsing JSON → mereka merancang backend pintar berbasis WebSocket
- Transfer data dioptimalkan menggunakan
encoding/gob milik Go
- Optimasi ukuran file WASM
- Ukuran awal file WASM: 32MB
- Setelah menerapkan kompresi Brotli → turun menjadi 4.6MB
- Karena sulit menangani kompresi di CDN, kompresi diterapkan langsung dalam proses build
Peningkatan lainnya
- Di luar masalah memori yang sudah diperkirakan, sebagian besar kekhawatiran ternyata tidak terbukti
- Menulis komponen UI tidak terlalu sulit, dan integrasi dengan layanan lain (Tailwind, Auth0, dll.) juga tidak bermasalah
- Paket NPM dapat digunakan di WebAssembly → interoperabilitas dengan JavaScript tetap terjaga
- Cara Go-app memperbarui komponen lebih fleksibel dibanding React, sehingga memberi keleluasaan optimasi yang lebih besar
- Analisis performa bisa dilakukan dengan tool profiling Go (
pprof) dan profiler bawaan browser
- Berkat dukungan PWA, aplikasi dapat dijalankan sebagai aplikasi desktop/mobile, sehingga bisa digunakan tanpa harus membuka browser
Manfaat yang diperoleh setelah transisi
- Konsistensi UI meningkat
- Karena TUI dan web UI memakai codebase yang sama, UX yang dihasilkan menjadi lebih konsisten
- Performa dan penggunaan memori membaik
- Saat menangani data besar, kecepatan rendering meningkat dan penggunaan memori menurun
- Produktivitas tim meningkat
- Sebelumnya, web UI dan TUI harus dioptimalkan secara terpisah,
sekarang satu kali optimasi bisa diterapkan ke kedua antarmuka sekaligus
- Hasilnya, mereka bisa lebih fokus mengembangkan fitur baru
Apakah perlu beralih ke Go + WASM?
- Secara umum tidak direkomendasikan, tetapi bisa berguna dalam kondisi tertentu:
- Tim dengan banyak pengembang Go
- UI kompleks di mana TypeScript/React menunjukkan batas performa
- Ada kebutuhan berbagi kode antara TUI dan web UI
- Lingkungan yang menuntut kecepatan pengembangan semaksimal mungkin
- Jika sesuai dengan kondisi di atas, Go + WASM bisa menjadi alternatif yang baik
Namun, dalam kebanyakan kasus, teknologi web yang ada (React, TypeScript, dll.) tetap lebih cocok
6 komentar
Apakah ini seperti GWT yang dulu?
Hmm... saya penasaran apakah pengembangannya akan jadi lebih type-safe dibanding TS.
Bagaimanapun dilihat, ini terasa seperti menyelesaikan masalah yang mudah dengan cara yang lebih rumit...
Frontend berbasis Go ternyata lebih efektif daripada yang saya kira. Ternyata ada alasan mengapa use case-nya terus bertambah.
Tetap saja, saya ingin mencobanya.
Komentar Hacker News
Ada pendapat bahwa sebagai tim kecil, mereka perlu merilis dengan cepat
Mereka memiliki tim engineer Go yang kuat dan UI kompleks yang sulit diskalakan dengan TypeScript/React
Ada kekhawatiran apakah ini framework yang "merender ke canvas", tetapi ternyata tidak
Mereka memutuskan membangun frontend menggunakan <a href="https://go-app.dev/" rel="nofollow">https://go-app.dev/</a>;
Ada pendapat bahwa Go tidak cocok untuk jenis pekerjaan seperti ini
Akan menarik melihat laporan lanjutan beberapa bulan ke depan tentang apakah perpindahan dari stack yang lebih berat ke stack yang lebih performant namun agak tidak biasa ini membawa hasil positif
Pencipta go-app menemukan postingan ini dan merasa terkejut, sambil mendoakan kesuksesan produknya
Karena Go WASM lambat dalam mem-parsing JSON, mereka mengubah arsitektur dan membuat "backend pintar" untuk pemuatan data bertahap melalui WebSockets
Ada pendapat bahwa WASM cocok untuk use case ceruk tertentu, tetapi kurang tepat untuk membangun web app umum
Ada yang menganggap penggunaan bahasa yang sama untuk semua komponen (frontend/backend/app) memiliki nilai yang besar