Ada satu pengalaman digital yang sangat berkesan bagi saya: ketika diberi kepercayaan untuk membantu menyiapkan sistem digital rekrutmen Tim Ekspedisi Patriot 2026 Kementerian Transmigrasi.
Pada awalnya, project ini mungkin terdengar sederhana: membuat sistem pendaftaran.
Namun dalam praktiknya, ini jauh lebih besar dari itu.
Ini adalah bagian dari agenda rekrutmen nasional level kementerian, yang melibatkan kampus-kampus mitra terbaik, jaringan pemerintah pusat dan daerah, kanal promosi publik berskala luas, tokoh-tokoh nasional, serta ribuan calon peserta dari berbagai daerah, kampus, disiplin ilmu, dan latar sosial-budaya di Indonesia.
Program ini melibatkan 10 kampus mitra, yaitu Universitas Indonesia, Universitas Gadjah Mada, Institut Teknologi Bandung, IPB University, Universitas Airlangga, Universitas Diponegoro, Universitas Padjadjaran, Universitas Hasanuddin, Universitas Brawijaya, dan Institut Teknologi Sepuluh Nopember.
Rekrutmen ini juga dipromosikan melalui berbagai kanal besar: oleh 10 kampus mitra, melalui 73 titik promosi di 5 bandara utama di Pulau Jawa, 10 stasiun kereta tersibuk di Jakarta, dinas tenaga kerja dan transmigrasi di seluruh Indonesia, beberapa kementerian/lembaga lain, serta figur publik dan influencer besar, termasuk Raffi Ahmad dan Brisia Jodie.
Promosi juga diperkuat melalui event lari yang melibatkan tokoh-tokoh kunci nasional, antara lain Menko AHY, Menteri Transmigrasi, dan Wakil Menteri Ketenagakerjaan. Karena itu, sistem yang dibangun tidak hanya mendukung pendaftaran, tetapi juga mendukung dashboard event lari sebagai bagian dari kampanye promosi yang terintegrasi.
Dalam situasi waktu yang sangat mepet, vendor yang semula diharapkan mengerjakan sistem ini tidak sanggup menyelesaikannya sesuai kebutuhan. Saya kemudian diminta membantu.
Dalam hitungan hari, saya menyusun konsep, arsitektur, alur kerja, struktur data, model kewenangan pengguna, serta sistem digital yang dibutuhkan untuk mendukung proses rekrutmen nasional tersebut.
Hasilnya bukan sekadar formulir pendaftaran online. Sistem ini berkembang menjadi ekosistem digital rekrutmen terintegrasi, yang mencakup formulir pendaftaran nasional, dashboard admin real-time, dashboard analitik eksekutif, dashboard event lari, dashboard media, dashboard broadcast, serta sistem multi-level authority agar akses, pemantauan, dan pengelolaan data dapat dilakukan sesuai kewenangan masing-masing pengguna.
Skala Project
Hingga penutupan pendaftaran pada 21 Mei 2026 pukul 24.00 WIB, program ini diminati lebih dari 177.000 orang, dikunjungi lebih dari 328.000 kali, dan mencatat 10.359 pendaftar.
Lebih dari sekadar angka, data ini menunjukkan keluasan partisipasi nasional: pendaftar berasal dari ribuan kampus, ratusan kelompok suku bangsa, berbagai program studi, serta beragam daerah di Indonesia. Dashboard mencatat 1.980 kampus lainnya di luar 10 kampus teratas, 2.628 kelompok program studi lainnya di luar 10 prodi terbanyak, serta 592 kelompok suku bangsa lainnya di luar 10 suku terbanyak.
Bagi saya, yang membuat project ini penting bukan hanya jumlah kunjungan atau jumlah pendaftarnya. Yang lebih bermakna adalah kompleksitas di baliknya.
Sistem ini harus melayani kebutuhan publik, kebutuhan admin, kebutuhan verifikator, kebutuhan pimpinan, kebutuhan promosi, dan kebutuhan pengambilan keputusan secara real-time. Semua harus berjalan dalam satu ekosistem yang stabil, mudah digunakan, dan bisa dipantau.
Tech Stack: Sengaja Dibuat Ringan, Cepat, dan Tahan Tekanan
Salah satu keputusan penting dalam project ini adalah memilih pendekatan teknologi yang paling sesuai dengan situasi: waktu sangat terbatas, kebutuhan cepat berubah, traffic berpotensi melonjak, tim kecil, dan tidak ada ruang untuk kompleksitas infrastruktur yang tidak perlu.
Karena itu, sistem ini tidak menggunakan bundler atau framework JavaScript modern seperti React, Vue, Angular, Webpack, Vite, atau Rollup. Sistem ini sengaja dibangun dengan pendekatan vanilla no-build, dengan Firebase sebagai backend.
Prinsipnya sederhana: semakin sedikit lapisan yang tidak perlu, semakin cepat sistem bisa dibangun, diuji, diperbaiki, dan di-deploy.
Frontend
Di sisi frontend, sistem ini menggunakan HTML5 statis multi-page. Setiap fitur utama dibuat sebagai file .html tersendiri, seperti halaman utama, dashboard admin, dashboard lari, dashboard media, dashboard broadcast, dan halaman-halaman pendukung lainnya.
Untuk tampilan, sistem menggunakan CSS3 murni, dengan custom properties, grid, dan container queries. Tidak menggunakan Tailwind, SCSS, atau framework styling lain. File CSS dipisah per halaman dan dilengkapi styles.css global agar struktur tetap rapi dan mudah dikontrol.
Untuk logika aplikasi, sistem menggunakan JavaScript ES Modules vanilla melalui <script type="module">. Tidak ada React, Vue, Angular, Webpack, Vite, ataupun Rollup. Pendekatan ini membuat sistem tetap ringan, mudah dibaca, dan cepat diperbaiki saat dibutuhkan.
Untuk visualisasi data, dashboard menggunakan Chart.js 4.4.1 melalui CDN jsDelivr. Chart ini digunakan untuk menampilkan bar chart, donut chart, dan line chart pada dashboard admin.
Untuk kebutuhan ekspor data, sistem menggunakan SheetJS/xlsx 0.18.5 melalui CDN, sehingga data pendaftar dapat diekspor ke format .xlsx.
Untuk bukti e-ticket atau bukti pendaftaran, sistem menggunakan html2canvas 1.4.1 secara lazy-load. Dengan ini, kartu bukti pendaftaran dapat di-render menjadi gambar PNG secara client-side.
Sistem juga menggunakan Google Fonts dengan preconnect untuk menjaga tampilan tetap profesional, serta Google Analytics/gtag.js untuk tracking visitor.
Backend: Firebase sebagai BaaS
Di sisi backend, sistem menggunakan pendekatan Backend-as-a-Service dengan Firebase.
Firebase Hosting digunakan sebagai static hosting dengan CDN global. Hosting ini juga mengatur URL rewrites untuk halaman seperti /admin, /lari, /media, dan halaman lainnya, serta cache headers berdasarkan jenis file.
Cloud Firestore dengan Firebase SDK modular v10.13 menjadi database utama. Firestore digunakan sebagai database NoSQL realtime untuk berbagai koleksi, seperti registrations, admins, editLogs, lariPatriot, lariPatriotStats, mediaAttendance, patriotMove, publicFeed, dan koleksi pendukung lainnya.
Firebase Auth v10.13 digunakan untuk login admin melalui Google Sign-In dengan popup. Sistem ini mendukung role-based access control, seperti viewer, verifikator, editor, dan admin.
Cloud Storage v10.13 digunakan untuk upload berkas pendaftar, seperti KTP, ijazah, foto, dan dokumen pendukung lainnya.
Sementara itu, Firestore Rules dan Storage Rules digunakan sebagai lapisan keamanan utama. Rules tidak hanya berfungsi sebagai pembatas akses, tetapi juga untuk validasi schema, role-based access control, atomic quota enforcement, serta deadline enforcement di sisi server.
Dengan kata lain, validasi penting tidak hanya dilakukan di client, tetapi juga ditegakkan di sisi server melalui security rules.
Pola Arsitektur Kunci
Secara arsitektur, sistem ini dibangun dengan beberapa prinsip utama.
Pertama, no-build dan CDN-first. Firebase SDK dan semua library dimuat dari gstatic, jsDelivr, atau cdnjs. Tidak ada npm install, tidak ada proses compile, dan tidak ada build step. Polanya sederhana: edit, test, lalu firebase deploy.
Kedua, sistem menggunakan shared module. File firebase-services.js menjadi single source of truth untuk semua fungsi Firebase, lalu diimpor oleh setiap halaman yang membutuhkan.
Ketiga, sistem menggunakan atomic transactions melalui runTransaction dan server timestamps. Ini penting untuk menangani kuota event lari, deduplikasi nomor telepon, dan mencegah race condition.
Keempat, dashboard menggunakan realtime listeners melalui onSnapshot, sehingga data di dashboard dapat ter-update otomatis tanpa polling manual.
Kelima, sistem dirancang security-first. Duplikasi, kuota, deadline, dan kewenangan akses ditegakkan melalui Firestore Rules, bukan hanya di sisi client.
Keenam, sistem menerapkan cache strategy melalui firebase.json: HTML dibuat always-revalidate, JS/CSS no-cache, sementara assets immutable disimpan hingga satu tahun.
Mengapa Stack Ini Tepat untuk TEP?
Untuk konteks rekrutmen Tim Ekspedisi Patriot, pendekatan ini sangat relevan.
Pertama, dari sisi operational simplicity. Tidak perlu maintain server, container, CI/CD pipeline, atau runtime Node/Python. Deploy dapat dilakukan dengan firebase deploy dalam waktu singkat. Rollback juga dapat dilakukan dari Firebase Console. Karena tidak ada build step, tidak ada risiko dependency hell, tidak ada node_modules raksasa, dan tidak ada masalah klasik “works on my machine”.
Kedua, dari sisi biaya, stack ini sangat efisien. Untuk skala ribuan pendaftar per hari, Firebase free tier masih sangat membantu. Hosting CDN, Firestore, dan Storage dapat digunakan tanpa beban infrastruktur besar di awal.
Ketiga, dari sisi skalabilitas, Firebase Hosting berjalan di CDN global Google dan Firestore memiliki kemampuan auto-scaling. Ini penting untuk sistem yang traffic-nya bisa melonjak tajam karena dipromosikan secara nasional melalui kampus, bandara, stasiun, dinas daerah, kementerian/lembaga, dan influencer besar.
Keempat, dari sisi keamanan, banyak komponen kelas enterprise sudah tersedia secara bawaan: OAuth Google, TLS, proteksi infrastruktur Google Cloud, IAM, serta security rules. Firestore atomic transaction juga membantu mencegah race condition tanpa perlu membuat lock manual di backend terpisah.
Kelima, dari sisi realtime, Firestore memberi kemampuan live update secara natural. Dashboard admin dapat berubah otomatis ketika ada pendaftar baru, tanpa perlu setup WebSocket, Redis pub/sub, atau backend realtime tambahan.
Keenam, dari sisi time-to-market, pendekatan ini memungkinkan satu developer merilis fitur baru dalam hitungan jam. Fitur seperti dashboard lari, dashboard media, dan dashboard broadcast dapat ditambahkan secara inkremental tanpa provisioning database, migration, atau deploy backend terpisah.
Ketujuh, dari sisi portabilitas, meskipun ada vendor lock-in ke Firebase, lock-in ini relatif terkendali. Karena frontend menggunakan HTML, CSS, dan JavaScript vanilla, jika suatu hari perlu pindah ke Supabase, Appwrite, atau backend lain, sebagian besar frontend tetap dapat dipertahankan. Yang terutama perlu diubah adalah layer firebase-services.js.
Kedelapan, dari sisi offline-friendly, Firestore mendukung cache dan persistence untuk auth state. Bukti pendaftaran juga dapat di-render client-side melalui html2canvas, sehingga lebih ramah untuk kondisi koneksi pengguna yang tidak selalu ideal.
Trade-off yang Disadari
Tentu, setiap pilihan teknologi punya konsekuensi.
Karena sistem ini multi-page, navigasi antar halaman menggunakan full refresh, bukan single-page application. Namun untuk konteks formulir pemerintahan, ini justru dapat menjadi kelebihan: lebih ringan, sederhana, dan mudah dipahami.
Ketergantungan pada CDN juga menjadi catatan. Jika jsDelivr atau cdnjs mengalami gangguan, sebagian fitur seperti chart atau export dapat terdampak. Mitigasinya dilakukan melalui preconnect dan fallback jika dibutuhkan.
Firestore juga punya keterbatasan query. Tidak ada JOIN seperti database relasional, dan agregasi besar dapat menjadi mahal jika dataset tumbuh sangat besar. Namun untuk skala TEP yang berada pada puluhan ribu pendaftar, pendekatan ini masih sangat memadai.
Vendor lock-in ke Firebase juga ada. Namun dengan pemisahan service layer dan penggunaan vanilla JavaScript, risiko tersebut tetap dapat dikelola.
Sistem yang Harus Tetap Hidup Saat Live
Tantangannya semakin besar karena sistem ini tidak dibangun dalam kondisi ideal.
Proses rekrutmen sudah berjalan, kampanye publik berlangsung di banyak kanal, traffic pengguna terus masuk, dan sistem tetap harus diperkuat sambil live. Upgrading, penyesuaian, dan penguatan sistem dilakukan paralel tanpa mengganggu pengalaman pengguna.
Dalam kondisi seperti itu, pilihan arsitektur yang sederhana, ringan, dan cepat sangat menentukan. Sistem harus cukup fleksibel untuk berubah cepat, tetapi cukup kuat untuk tetap stabil.
Alhamdulillah, sistem berjalan stabil. Ia mendukung rekrutmen nasional level kementerian, melayani ratusan ribu kunjungan, mencatat lebih dari sepuluh ribu pendaftar, mengelola data dari ribuan latar akademik dan sosial-budaya, serta berjalan tanpa komplain dari pengguna.
Penutup
Pengalaman ini mengingatkan saya bahwa transformasi digital bukan hanya soal membangun aplikasi.
Transformasi digital adalah tentang memahami kebutuhan kelembagaan, merancang arsitektur yang tepat, menerjemahkan kompleksitas menjadi sistem yang mudah digunakan, dan memastikan teknologi benar-benar bekerja saat paling dibutuhkan.
Dalam project ini, stack yang dipilih bukan yang paling “wah” secara teknologi, tetapi yang paling tepat untuk konteksnya: produk pemerintahan/event-based, tim kecil, deadline ketat, traffic spiky, kebutuhan reliability tinggi, dan keterbatasan budget infrastruktur.
Dalam situasi kritis, sistem tidak cukup hanya “jadi”.
Ia harus benar-benar berfungsi.