Perjalanan Pembuatan Aplikasi SaaS

Pembuatan aplikasi SaaS tidak mudah. SaaS singkatan dari Software as a Service yang artinya Software menjadikan sebagai pelayanan itu sendiri. Berbeda dengan software zaman dahulu yang berpusat pada satu sistem dan berjalan berdasarkan file atau berkas. Software jarang terintegrasi ke satu sistem sehingga membutuhkan Database. SaaS merupakan software yang telah menyatukan berbagai kebutuhan dan terkumpul dalam Database yang terintegrasi.

Saya membuat aplikasi SaaS manajemen keuangan bernama Sakuarua sejak tahun 2024—versi 1.0— untuk penggunaan sendiri, tetapi sejak tahun 2026—versi 2.0— saya melakukan rewriting karena secara konsep data dan sistem sudah salah dan sulit untuk dikembangkan.

Perjalanan ini memberikan saya banyak pelajaran sehingga saya pikir layak untuk dibagikan, baik untuk diri saya sendiri atau kamu semua.

Blog lainnya:

Pondasi sistem dan Arsitektur

Software ini dibangun menggunakan paradigma Front-end (FE) dan Back-end (BE). Walaupun dikerjakan sendiri, paradigma ini membantu untuk memecahkan masalah menjadi kecil dan pengelompokan berbagai solusi menjadi solusi yang bisa digunakan berkali-kali—konsep komponen dalam framework FE.

Saya menggunakan Framework Frontend Vue.js, dan State Management Pinia. Berbeda dengan versi 1.0 menggunakan React.js. Alasan diganti adalah saya ingin mencoba bagaimana Vue.js versi 3 berjalan. Sejauh ini saya merasa nyaman dan tidak sulit.

Pada sisi Backend menggunakan Express.js karena saya ingin fleksibilitas pada berbagai bagian, berbeda pula dengan versi 1.0 menggunakan Nest.js. Saya sudah paham pola dan arah pengembangan sehingga saya bisa membuat backend sesuai kebutuhan.

Arsitektur Front-end

Frontend menggunakan beberapa konsep untuk memudahkan pengembangan:

Layout: Komponen besar yang mengelola layout secara keseluruhan
Pages: Halaman-halaman aplikasi dalam sistem
Routes: Mapping alamat kepada halaman
Stores: State Management
Components: Daftar komponen global
Composables: Function reusable untuk lingkungan Vue, mirip hooks di React
Events: List event yang dapat didengar oleh siapapun dalam apliakasi
lib: Beberapa fungsi atomic yang dapat digunakan
Repository: Data Management

Walaupun menggunakan state management seperti pinia, saya menggunakan aturan penting

Hanya pages yang boleh modifikasi state global, komponen lain tidak boleh modifikasi state global kecuali melewati props yang di panggil oleh pages.

Aturan ini penting diikuti karena side-effect tanpa manajemen yang baik akan memberikan behaviour aplikasi yang tidak terduga.

Arsitektur Backend

Backend dikembangkan dari 0, saya membuat beberapa aturan penting seperti:

Modules: Sekumpulan modul yang tidak berkaitan langsung pada fungsi aplikasi, bersifat netral dan bergerak pada area general. Sebagai contoh Authentication, database, rate-limiter, swagger, dan lain-lain.
Services: Merupakan area fitur aplikasi itu sendiri, misalnya manajemen buku besar, account, reporting. Bisa dikatakan disini mengatur User Area.
Events: Mengatur beberapa event perubahan penting didalam aplikasi, baik itu event dari modules maupun services.
Repository: Manajemen data yang langsung berinteraksi pada database.
Specs: Sekumpulan unit testing pada beberapa proses API maupun internal fitur.
utils: fungsi atomic yang dapat digunakan dimana saja.

Aturan: Repository Pattern

Pembuatan projek ini bukan hal mudah apabila ingin membuatnya menjadi scalable.

Repository Pattern adalah memberikan abstraksi terhadap akses data dengan membuat Class Repository. Umumnya memberikan akses langsung ke database lewat router atau service yang sedang menggunakannya terlihat mudah dan cepat dalam pengembangan, tapi tidak memiliki abstraksi apapun sehingga sangat terikat langsung pada database.

Abstraksi menjadi esensial dalam pembuatan aplikasi untuk menghilangkan bagian-bagian yang tidak penting dan memberikan lapisan kontrol terhadap akses internal.

Banyak bagian dari aplikasi ini saya gunakan repository pattern, tidak hanya di backend, tetapi juga di frontend sehingga memberikan fleksibilitas lebih

Service Backend -> Repository Database -> Query Database
Service Frontend -> Repository API -> API Call

Repository Database memungkinkan untuk menyembunyikan query SQL yang kompleks.

Keuntungan Repository pattern di Frontend adalah saya bisa memberikan lapisan tambahan seperti caching tanpa mengubah fitur didalam aplikasi, tanpa konsep ini akan sulit untuk memberikan lapisan tambahan pada akses data.

Manajemen Server

Saya sudah familiar Sistem Operasi Linux dan Ubuntu sejak 2020 sehingga bukan hal sulit untuk mengatur server sebagai solo developer—bisakah saya sebut indie developer?.

Kenapa menggunakan VPS dan tidak menggunakan vercel, Cloud, serverless? Jawaban singkatnya serverless dan kawan-kawan punya biaya yang bisa tidak terkendali sedangkan VPS hanya sekali bayar setiap bulannya dengan batasan spesifikasinya saja.

Setup server yang saya gunakan adalah:

Nginx: sebagai Web Server.
Postgresql: Database Management System.
fail2ban: mengatasi akses yang tidak diinginkan.

Menjalankan aplikasi seperti node.js secara daemon—menjalankan proses di background— saya coba menggunakan berbagai cara seperti:

Systemctl Daemon
Supervisord
PM2

Semuanya berjalan sesuai ekspektasi, untuk sekarang pm2 punya perintah untuk melihat log, proses aplikasi, dan manajemen proses yang lebih mudah dibanding lainnya.

Deployment dan Skrip Automasi

Manajemen deployment saya buat sesimpel mungkin. Menggunakan kode untuk berbagai kebutuhan seperti:

Development Script: Saya membuat kode untuk menjalankan berbagai proyek sekaligus dan paralel untuk kebutuhan development. Terinspirasi dari framework lainnya yang memiliki kode development.
Deployment Script: Menyiapkan kode untuk menjalankan berbagai kebutuhan deployment seperti build project, inisiasi database, hingga manajemen daemon.

Automasi deployment menggunakan CI/CD untuk mempercepat proses dan membentuk workflow kerja yang lancar.

Cloudflare Proxy

Cloudflare proxy memberikan perlindungan dari DDOS dan serangan hacker lainnya, terima kasih berikan secara gratis.

Lokasi VPS di Indonesia kadang membuat perjalanan koneksi jaringan lebih jauh karena harus ke singapur dahulu lalu ke Indonesia lagi, tapi sebagian besar waktu tidak ada masalah.

Meningkatkan Keamanan Aplikasi

Sistem apapun yang bersentuhan dengan internet pasti akan beriteraksi dengan hacker atau bot jahat yang secara aktif melakukan scan setiap hari, menit dan detik. Maka saya menyiapkan berbagai lapisan keamanan aplikasi

Meningkatkan keamanan SaaS terdiri dari berbagai lapisan apabila di memiliki kendali atas semua lapisan:

Lapisan aplikasi: Aplikasi harus membatasi akses, enkripsi, hashing password dan pemilihan algoritma random yang kuat.
Lapisan Server: Membatasi akses dari luar, mengamankan SSH, Database, melakukan backup harian.
Lapisan Jaringan: Mengamankan data dengan enkripsi end-to-end, pastikan berjalan di HTTPS.

Penyiapan diatas tidak cukup diatur satu kali, perlu melakukan pemantauan update keamanan baik dari Sistem Operasi, Software hingga library yang digunakan untuk mengatasi zero-day attack.

Caching

Cache merupakan data sementara yang dapat diakses secepat mungkin tanpa proses panjang sehingga penggunaan aplikasi terlihat instan.

Saya melakukan caching agresif pada berbagai area seperti:

Network: Membuat cache-control pada aset seperti css dan js.
Backend: Caching backend seperti session, database, dan akses.
Database: Caching database dengan menggunakan indexing.
Application: Membuat caching di level aplikasi saat user navigasi berbagai menu.

Manajemen caching juga diperlukan untuk menghindari konflik dan inkonsisten data.

Content Management

Manajemen konten dibuat untuk memberikan informasi, berita, hingga edukasi kepada pengguna tentang aplikasi ini. Selain untuk meningkatkan SEO juga untuk memberikan update terbaru kepada pengguna.

Software manajemen konten yang saya gunakan adalah wordpress karena fleksibilitas WYSIWYG sehingga manajemen konten lebih cepat dilakukan.

Progression

Saya senang mencatat progress tugas di github issue, saya pecah menjadi beberapa fase seperti versi 2.0.0, 2.1.0, hingga 2.2.0. Setiap fase memiliki arah tujuannya sendiri, seperti v2.0.0 inisiasi infrastruktur dan aplikasi. Versi 2.1.0 mengembangkan sebuah bibit menjadi lebih sempurna dan layak pakai. Versi 2.2.0 berfokus pada pengguna.

Fokus dari masing-masing fase membuat saya menjadi tahu arah kemana aplikasi ini berkembang. Tahu apa yang mungkin bisa dilakukan. Tanpanya arah pengembangan menjadi tidak terkendali dan hanya menambah-nambah fitur tanpa alasan yang jelas.

Setelah beberapa bulan berjalan, saya lihat pola setiap fase hidup selama 1 bulan lalu lanjut ke fase selanjutnya.

Mengembangkan SaaS Bukan Hal Mudah

Tantangan pembuatan SaaS adalah luasnya konteks dan manajemen data yang harus diperhatikan. Secara vertikal memikirkan dari database, backend, server hingga tampilan aplikasi. Sedangkan secara horizontal perlu memikirkan Keamanan, User Experience, dan kemudahan.

Membuat SaaS tidaklah sulit, dengan bantuan AI siapapun bisa membuatnya. Tetapi, mengembangkan dan menjaga SaaS tetap berjalan itu adalah bagian lebih sulit. Abaikan saja marketing dan membuat konten berkala karena itu hal yang lebih sulit.

Saya belajar banyak dari perjalanan ini, belajar ulang tentang berbagai hal untuk membuatnya berjalan sesuai yang saya inginkan. Saya tahu bahwa tidak ada ide yang tidak unik, tetapi eksekusi membuat itu menjadi nyata adalah bagian terberat yang mungkin tidak semua orang bisa bertahan kecuali memiliki motivasi yang kuat.

Closing

Terima kasih telah membaca perjalanans aya membuat Aplikasi Sakuarua. Bukan hal mudah dikerjakan sendiri, tapi saya menikmati setiap perjalanan ini. Silahkan subscribe blog ini untuk dapatkan konten menarik lainnya. Terima kasih

Sakuarua Journey: Perjalanan membuat aplikasi SaaS Scalable, Aman dan Cepat.