Arsitektur Microservice untuk Data Publik (Bagian 1)

Biar saya langsung bicara to the point : data publik di Indonesia itu payah karena 3 alasan.

1. Dikeluarkan oleh instansi lewat website atau publikasinya sendiri. Per wilayah pula. Singkatnya, scattered alias tersebar.
2. Format penyajian data tidak seragam dan sebagian sulit diolah ulang. Yang paling top adalah instansi yang sajikan data berformat CSV/JSON. Selain itu, ekspor sebagai spreadsheet (Excel) juga cukup oke. Namun dari observasi pribadi, kebanyakan data tersedia dalam bentuk PDF dan tabel HTML. PDF juga ada jenisnya. PDF teks masih dapat diproses. Kalau ada PDF hasil scan, itulah mimpi buruk pengguna data.
3. Data tidak konsisten antar instansi maupun wilayah. Di wilayah A, ada tiga item ditampilkan dalam laporan. Di wilayah B, empat item. Di wilayah C, ada empat item juga tapi dua item berbeda dengan wilayah B. Saya langganan geleng-geleng kepala ketika ketemu kasus seperti ini.

Contohnya, saya pernah coba kumpulkan data statistik BAZNAS per daerah. Ternyata setiap kabupaten/kota punya website BAZNAS sendiri dengan tingkat disiplin laporan bervariasi. Ada yang laporannya lengkap 5 tahun terakhir, ada yang kosong (per 15 Sep 2021). Format laporannya pun beragam, ada yang PDF, ada pula yang embedded sebagai tabel HTML.

Saya coba gali jalan alternatif. BAZNAS menerbitkan statistik zakat per tahun (ini contohnya). Sayangnya BAZNAS menggunakan kategori tier mereka sendiri: pusat, provinsi (digabung), kota/kabupaten(digabung). Dari sudut pandang pengguna umum, statistik ini sekedar laporan berdasarkan titik setor. Tidak ada value, tidak ada insight tambahan. Memangnya kenapa kalau BAZNAS pusat sekian, BAZNAS provinsi sekian? Kenapa tidak per kabupaten/kota, atau setidaknya per provinsi? Mungkin bisa didapat temuan menarik, misalnya korelasi antara jumlah zakat dengan indeks pembangunan manusia.

Jalan terakhir adalah menghubungi instansi BAZNAS untuk meminta data. Lalu saya ukur besarnya usaha yang dibutuhkan, lamanya waktu tunggu, belum lagi jumlah instansi yang dikontak. Untuk hobi mencari data, bukan tuntutan kerja/penelitian, saya nilai opsi ini tidak worth it. Akhirnya saya menyerah.

Sebuah Proposal Arsitektur Sistem

Tapi kalau berani bilang data publik payah, mestinya kasih solusi sekalian dong? Demikian kata haters.

Tentu saja.

Saya ada solusi untuk membuat data publik menjadi lebih bermutu. Tapi sebelum melangkah lebih jauh ke arsitekturnya, saya definisikan dulu data publik dan karakteristiknya. Saya pakai definisi UU No 14 Tahun 2008:

Informasi Publik adalah informasi yang dihasilkan, disimpan, dikelola, dikirim, dan/atau diterima oleh suatu badan publik yang berkaitan dengan penyelenggara dan penyelenggaraan negara dan/atau penyelenggara dan penyelenggaraan badan publik lainnya yang sesuai dengan Undang-Undang ini serta informasi lain yang berkaitan dengan kepentingan publik.

Intinya, data yang dibuat oleh instansi sektor publik, berhak diketahui publik, dan tidak bahaya jika dipublikasikan. Supaya lebih paham lagi, kita contohkan. Apakah daftar pejabat DPR termasuk data publik? Ya, sebab berkaitan dengan penyelenggaraan negara. Kalau data NIK? Tidak. Meskipun adanya NIK untuk keperluan administrasi negara, data tersebut termasuk yang dikecualikan menurut UU No 14 Tahun 2008.

Kemudian saya jabarkan karakteristik data publik serta konsekuensinya terhadap desain arsitektur yang akan saya buat.

1. Bisa diakses semua orang → tidak perlu authorization & authentication untuk read
2. Kebenaran dan keakuratan data adalah tanggung jawab instansi penerbit → perlu authorization & authentication untuk write
3. Data tidak sering mengalami perubahan → kita bisa optimalkan strategi untuk storage.
4. Data publik berasal dari banyak instansi sumber → perlu database untuk metadata data publik
5. Data yang dihasilkan instansi berformat beragam → perlu fungsi khusus untuk konversi ke format seragam
6. Data yang dihasilkan instansi bisa tidak seragam untuk satu jenis data → perlu ada validasi untuk setiap jenis data, paling bagus kalau ada definisi field data. Hal tersebut dapat diakomodasi oleh database.

Oke, sekarang sudah dapat beberapa spek solusi berdasarkan karakteristik data publik. Apa sudah bisa merancang solusinya? Hoho, tentu saja belum. Kita perlu mengetahui use case umum. Untuk apa sebenarnya orang mencari data publik? Berdasarkan pengalaman pribadi, ada dua penggunaan data publik.

1. Value lookup, alias cek referensi nilai. Contohnya cek kode bank, kode pos, dan sebagainya. Kita cari datanya, ketemu, sudah beres. Kehidupan berlanjut, musim berganti.
2. Analisis lanjutan yang memerlukan data dasar. Misalnya, sebuah perusahaan bimbel mau membuka cabang di kota baru. Kota mana saja yang akan dipilih? Mereka memutuskan mencari berdasarkan PDB dan populasi penduduk usia sekolah (misal 7–16 tahun). Di sini data publik berperan sebagai bahan baku analisis ekspansi pasar, dengan pola pemakaian spesifik seperti memakai query SQL.

Berdasarkan karakteristik data publik dan use case umum, saya jabarkan satu-satu keputusan arsitektur solusi saya. Sekalian saya membangun diagram arsitekturnya.

Tahap 1 : Microservice tanpa DB

Data yang diakses user jarang berubah dan terbuka. Kemudian dari sisi use case, tidak ada tuntutan response time. Ini membuat saya mempertimbangkan akses data. Saya bisa manfaatkan database maupun file untuk storage. Saya putuskan menggunakan file JSON karena lebih mudah dan murah. Menurut saya, pilihan ini menjadi kelebihan terbesar arsitektur:

Layanan inti untuk data publik tidak butuh database

Diagram 1: Arsitektur microservice untuk data publik, mode paling sederhana

Diagram 1 menunjukkan bagaimana kita bisa membuat microservice tanpa database.

1. kita olah data mentah secara manual, atau kerennya data wrangling, sampai jadi format JSON.
2. Kita upload JSON ke repository. Nantinya repository ini berfungsi sebagai 3 hal : lokasi data, source code, dan dokumentasi API. Repository ini menggunakan CI/CD untuk memudahkan deploy ke server (lihat garis C).
3. Server dapat menggunakan static server yang ringan. Ingat, kita tidak pakai database, jadi microservice ini setara website statis.
4. User dapat mengakses microservice dan dapat melihat dokumentasi di repository (lihat D dan E).

Di artikel berikutnya, akan saya contohkan implementasi arsitektur ini dengan Next.JS + Vercel. (Lihat artikel penuh di sini)

Tahap 2 : File Automation + Metadata

Katakanlah kita sudah berhasil membuat microservice untuk data publik dengan cara seperti tahap 1. Untuk dua-tiga data publik beres lah. Kalau sudah menumpuk ratusan dokumen, tamat kita kalau pakai arsitektur sama. Kalau sudah begini, upgrade ke tahap 2. Hasilnya dapat dilihat di Diagram 2.

Diagram 2 : Arsitektur microservice data publik dengan tambahan automation dan metadata

Fokus peningkatan tahap ini adalah kapabilitas automation dan metadata. Automation artinya membuat proses upload, wrangling, konversi ke JSON, dan menyimpan ke repository jadi otomatis. Sementara metadata berarti tracking dokumen yang sudah diunggah dan diproses supaya mudah diakses.

1. Praktiknya begini. Misalkan 100 dokumen diunggah untuk dibuat REST API nya. Akan ada service/function untuk mengunggah dan simpan file mentahan. Jika sistem ditaruh di cloud macam AWS, penggunaan lambda function akan lebih hemat biaya.
2. Setelah itu ada service/function untuk mengubahnya menjadi file JSON (lihat garis C). Dari situ, ada dua aktivitas yang dijalankan. Pertama, menyimpan file JSON ke repository seperti Github (garis F). Selanjutnya, menyimpan metadata file JSON ke metadata service (garis D). Repository menyimpan isi file, sementara metadata service menyimpan lokasi penyimpanan file dan menyediakan direktori untuk memudahkan pencarian API.
3. Microservice data publik di-deploy dari repository (garis G).
4. User mengecek daftar API yang tersedia lewat API directory service (lihat I1 dan I2). Setelah ketemu alamatnya, user bisa akses API yang tersedia (lihat garis H).

Tahap 3 : Tambahan Auth

Karena instansi penerbit bertanggung jawab atas data publik, kita perlu lindungi sisi internal client. Implementasinya sederhana saja, cukup tambahkan auth service lengkap bersama database.

Diagram 3 : Arsitektur microservice data publik dengan tambahan auth

Tahap 4 : Automated File Distribution & API Generator

Kecuali bekerja di eselon kementrian atau punya pendanaan series A, anda belum butuh arsitektur ini. Tahap 4 ini mengandung kata-kata scalable, complex, over-engineered, dan expensive. Tapi tentunya menyenangkan untuk menganalisis sebarapa jauh proses bisnis jadi otomatis.

Kekurangan terbesar arsitektur ini hingga tahap 3 adalah adanya edge API repository. Itu menunjukkan beban kerja manual dari sisi developer. Kalau ada 100 dokumen yang akan dibuat API nya, developer perlu 100 kali membuat API. Meskipun hanya request GET dengan filter semua kolom, itu tetap beban yang memperlambat usaha scaling-up. Saatnya untuk membuatnya jadi otomatis. Hasilnya bisa dilihat di Diagram 4.

Diagram 4 : Arsitektur microservice versi lengkap, scalable, dan over-engineered. Lakukan ini kalau anda punya banyak duit.

Proses otomatis nantinya terdiri dari dua langkah.

1. Distribusi file JSON ke CDN. Jika sebelumnya file JSON diberikan ke repository, kali ini file JSON diteruskan ke service/function lain (garis H) yang akan mengunggahnya ke CDN (lihat garis L). Setelah itu, data file address di CDN akan disimpan lewat metadata service (garis J). Distribusi yang sukses akan memicu trigger untuk memanggil service/function kedua (lihat garis I).
2. Generator API. Service/function ini secara otomatis akan membaca file JSON, mendeteksi field JSON, lalu membuat API baru. Setelah itu, API baru segera di-deploy (lihat garis M). Address API akan disimpan di metadata service (lihat garis K).

Penutup: Siapkah Beralih?

Sekarang, sudah ada rancangan untuk menyediakan data publik. Masalahnya tinggal kesiapan dan keinginan untuk beralih. Solusi ini tidak menjadikan kita secanggih sektor publik Estonia yang sudah 99% online, tapi saya percaya data yang transparan dan accessible akan membuka jalan kemajuan.

Artikel ini adalah bagian dari Serial Arsitektur Microservice untuk Data Publik. Lihat artikel bagian 2 di sini (Bagian 2). Lihat juga artikel lain tentang teknologi dan implementasinya untuk berbagai industri di Medium dan dev.to saya. [Yogi Saputro : Full Stack Developer | M.B.A | creating useful IT solutions]