Belum masuk angka karena belum production. Yang udah ada: endpoint baru tanpa ngebreak yang lama, integrasi sync dari API pusat FIK, dan keputusan stack yang masih jadi perdebatan internal.
Legacy code bukan musuh. Pertama kali aku lanjutin project orang lain, reaksiku takut salah. Tapi setelah pelan-pelan baca, ternyata yang ditulis angkatan atas cukup rapi — dan akhirnya ngerti kenapa keputusan mereka dibuat.
Backward compatibility itu harga mati. Endpoint yang udah dipakai prodi STI nggak boleh tiba-tiba rusak pas di-scale up ke FIK. Setiap perubahan harus dipikirin efek ke client yang sudah pakai.
Volume data = bom waktu. Response API pusat FIK jauh lebih besar dari ekspektasi. Kalau sync nggak hati-hati — pakai incremental, batch, atau streaming — server app bisa down. Itu belum kejadian, dan aku mau pastikan nggak kejadian.
Project ini beda dari semua yang pernah aku kerjain. Bukan bikin dari nol — tapi melanjutkan codebase yang ditulis angkatan atas Bengkel Koding. Awalnya reaksi pertama aku: takut salah. Bagaimana kalau aku nggak ngerti arsitekturnya? Bagaimana kalau perubahan yang aku bikin ngebreak yang udah jalan?
Tapi setelah pelan-pelan baca dan refactor pelan-pelan, ternyata codebase-nya nggak seburuk yang aku takutkan. Ada kekurangan di sana-sini, ada bagian yang bisa di-improve — tapi secara keseluruhan cukup rapi. Yang awalnya bikin takut, akhirnya jadi latihan yang menarik: belajar ngerti keputusan orang lain tanpa harus nanya satu-satu.
Tugas utama aku di sini: scale up dari prodi STI ke Fakultas FIK. Implikasi gampangnya: scope lebih besar, data lebih banyak, pengguna lebih banyak — tanpa rewrite dari awal. Aku bikin endpoint baru untuk handle data fakultas (yang sebelumnya cuma prodi), dan update beberapa endpoint existing supaya support scope yang lebih luas. Kuncinya: backward compatibility. Endpoint yang udah dipakai prodi STI harus tetep jalan, dan prodi STI yang lama harus tetep bisa akses data mereka. Itu constraint yang nge-reshape banyak keputusan teknis.
Tantangan yang lagi aku hadapi sekarang dan jujur belum sepenuhnya selesai: integrasi data dari API pusat FIK. Tiga hal yang bikin pusing:
Pertama, response-nya "sangat besar" — di luar ekspektasi. Nested object, relasi yang banyak, dan pagination yang nggak konsisten. Kalau di-fetch naively, server app bisa kehabisan memory atau response time-nya ancur. Strateginya: batch processing, pilih field yang dibutuhin aja, dan kemungkinan tambahin caching layer. Belum final, masih eksplorasi.
Kedua, policy dan aturan dari API pusat. Rate limit, format request yang strict, dan waktu-waktu tertentu yang nggak boleh request. Itu di luar kontrol aku — dan aturan mainnya bukan aku yang nentuin. Integrasi bukan cuma soal kode, tapi juga soal negosiasi dan compliance ke tim pusat.
Ketiga, sync tanpa bikin server down. Pertanyaannya: kapan sync? Incremental atau full? Real-time atau batch pakai cron job? Setiap pilihan punya trade-off. Aku lagi coba dua pendekatan paralel — Laravel (karena stack existing dan udah familiar) dan Python (karena tooling data processing-nya lebih kuat).
Buatku ini project yang paling belum "selesai" di antara yang lain, dan justru itu yang bikin worth di-portofolio-kan. Banyak project portfolio yang nunjukkin "aku bikin dari nol" — tapi jarang yang nunjukkin "aku lanjutin, integrasi, dan pelan-pelan avoid ngebreak yang udah jalan." Itu skill yang beda, dan aku lagi belajarnya sekarang.
Hasilnya sementara: endpoint baru udah dibuat, endpoint existing udah di-update tanpa break, sync logic dari API pusat udah prototype. Yang belum: production cutover, testing di environment yang lebih besar, dan finalisasi pilihan stack. Project ini masih jalan, dan tiap minggu ada progress baru.