Oneapp

Konteks & masalah

Data reporting marketing berada di layanan backend, sementara layar laporan membutuhkannya dalam bentuk yang siap ditampilkan. Belum ada kontrak yang disepakati di antara keduanya, sehingga proses integrasi dan penampilan data itulah bagian yang paling lambat.

Pengguna & tim

Pengguna reporting marketing. Saya bekerja bersama tim backend yang memegang layanan sumber data laporan.

Kontribusi pribadi

• Memetakan data reporting yang benar-benar dibutuhkan frontend, bersama tim backend.
• Menyelaraskan kontrak API dengan peta data tersebut.
• Memvalidasi respons sebelum ditampilkan.
• Menata ulang cara aplikasi mengambil dan memproses data laporan.

Arsitektur & keputusan

Vue.js dan Quasar di frontend, Golang dengan Gin di backend, PostgreSQL sebagai database.

Keputusan yang menentukan adalah urutannya: sepakati peta data lebih dulu, perbaiki kontrak API berikutnya, sesuaikan frontend terakhir. Dengan bentuk data dikunci di level kontrak, frontend tidak lagi perlu menambal respons yang tidak bisa diprediksi.

Fitur utama

• Data laporan dikirim melalui layanan API yang terdefinisi.
• Respons divalidasi sebelum sampai ke layar.
• Pengambilan dan pemrosesan data laporan ditangani di satu tempat pada frontend.

Tantangan & solusi

Bagian sulitnya bukan mengambil datanya, melainkan menyepakatinya. Frontend butuh field tertentu dalam bentuk yang bisa diprediksi, sedangkan backend menyediakan apa yang sudah ada di layanannya.

Memetakan field yang dibutuhkan lebih dulu memberi kedua tim satu acuan yang sama. Kontrak API kemudian dikunci mengikuti peta itu, respons divalidasi saat diterima, dan alur pengambilan serta pemrosesan data disederhanakan agar sejalan.

Hasil

Data laporan kini mengalir melalui satu kontrak API yang disepakati, sehingga yang tampil di laporan sama dengan yang dikembalikan backend.