Pada 19 Juni 2025, saya menghadiri PiterJS #79 di St. Petersburg. Tema malam itu justru menarik karena tidak glamor: bukan bagaimana mengirim fitur berikutnya, tetapi bagaimana memelihara sesuatu yang sudah dibangun — monitoring, deployment, dan refactoring.
Programnya sangat sesuai dengan tema tersebut. Pavel Shlykov membahas cara memperbaiki monolit lama, Alexander Panfilov membahas FrontOps, dan Igor Antonov membahas metrik performa aplikasi web. Saya pulang dengan catatan praktis dari ketiga topik itu.
Bagian yang tidak saya duga adalah Q&A. Saya akhirnya memenangkan dua hadiah karena mengajukan pertanyaan terbaik selama sesi berlangsung. Itu hal kecil, tetapi justru menjadi detail yang paling saya ingat karena menguatkan alasan saya masih menghargai meetup teknis secara langsung: kita bisa melakukan lebih dari sekadar menyimak presentasi yang sudah disiapkan. Kita bisa menguji pemahaman sendiri ketika orang yang baru saja menjelaskan topiknya masih berada di ruangan yang sama.
Tema yang berguna adalah maintenance, bukan kebaruan
Acara frontend mudah berubah menjadi parade framework, API, dan abstraksi baru. PiterJS #79 terasa lebih membumi. Tema yang diumumkan adalah bagaimana mendukung software yang sudah ada.
Ini penting karena banyak pekerjaan engineering baru benar-benar dimulai setelah release pertama berhasil. Monolit legacy tidak otomatis berarti sistem yang buruk, dan “modernisasi” tidak otomatis berarti menulis ulang semuanya. Pertanyaan praktis biasanya lebih sempit: batasan apa yang benar-benar menyakiti sistem saat ini, dan perubahan apa yang bisa mengurangi masalah itu tanpa menciptakan risiko yang lebih besar daripada yang dihilangkannya?
Itu juga sebabnya ketiga talk terasa saling melengkapi. Refactoring mengubah kode. FrontOps mengubah cara frontend dibangun, dikemas, dikirim, dan dioperasikan. Pekerjaan performa mengubah cara kita mengukur hasilnya. Semuanya adalah lapisan berbeda dari masalah yang sama: menjaga sistem nyata tetap dapat dipahami dan dikendalikan setelah sistem itu tumbuh.
FrontOps lebih luas daripada sebuah Dockerfile
Salah satu catatan saya dari meetup adalah tentang menerapkan FrontOps dengan Docker. Pembedaan yang penting adalah: Docker adalah alat, bukan definisi FrontOps.
Tanggung jawab frontend tidak selalu selesai saat npm run build berhasil. Di production, tetap ada yang harus memikirkan build yang reproducible, bagaimana artifact dikemas, bagaimana konfigurasi masuk ke aplikasi, rollback release, perilaku cache, dan bagaimana kegagalan diamati. Container dapat membuat sebagian pekerjaan itu lebih terprediksi, tetapi tidak menggantikan keputusan operasionalnya.
Ini mengoreksi model mental yang cukup umum: build yang sukses membuktikan bahwa proses build selesai. Itu tidak membuktikan bahwa aplikasi akan di-deploy dengan benar, berperilaku benar di production, atau mudah dipulihkan saat sesuatu gagal.
Performa dimulai dari menentukan arti “lambat”
Talk tentang performa terasa sangat praktis dalam cara membingkai pengukuran. Cakupan yang diumumkan mencakup faktor yang memengaruhi kecepatan loading, berbagai metrik performa frontend, cara mengukur apa yang dimaksud dengan “lambat”, bahkan pertanyaan mengapa optimasi tidak selalu diperlukan.
Poin terakhir mudah diremehkan. “Buat lebih cepat” terdengar objektif, tetapi tanpa metrik dan masalah yang benar-benar terlihat oleh pengguna, itu bisa berubah menjadi tebakan yang mahal. Proses performa yang berguna dimulai dengan mendefinisikan apa yang sebenarnya lambat, mengukurnya, menemukan bottleneck, mengubah satu hal yang relevan, lalu mengukur lagi.
Sebuah metrik bukanlah user experience itu sendiri, tetapi memberi diskusi satuan yang sama. Tanpa pengukuran, pekerjaan performa bisa berubah menjadi kumpulan perubahan yang terlihat mengesankan secara teknis tanpa bukti jelas bahwa masalah yang benar-benar penting menjadi lebih baik.
Q&A mengubah nilai meetup bagi saya
Saya bisa saja menonton rekamannya dan mengumpulkan link setelah itu. Yang jauh lebih sulit direproduksi adalah interaksi di sekitar talk. Mengajukan pertanyaan yang baik memaksa kita memadatkan ketidakpastian menjadi sesuatu yang cukup spesifik untuk dijawab engineer lain.
Memenangkan dua hadiah memang menyenangkan, tetapi pelajaran yang lebih berguna jauh lebih sederhana: datang dengan kesiapan untuk berpartisipasi membuat meetup offline jauh lebih bernilai daripada memperlakukannya seperti playlist YouTube live.
Pertanyaan teknis yang kuat biasanya punya konteks dan constraint. Alih-alih bertanya “Arsitektur apa yang terbaik?”, sering kali lebih berguna bertanya trade-off apa yang berubah ketika tim tidak bisa menulis ulang sistem legacy, ketika deployment harus tetap backward-compatible, atau ketika sebuah metrik membaik tanpa manfaat yang sepadan dan terlihat oleh pengguna.
Ini bukan berarti setiap pertanyaan harus terdengar pintar. Pertanyaan yang baik seharusnya membantu membuka asumsi, batas, atau failure mode.
Apa yang akan saya bawa ke meetup teknis berikutnya
- Tahu mengapa sebuah talk relevan bagi saya. Tulis satu masalah nyata atau ketidakpastian sebelum sesi dimulai.
- Pisahkan pengalaman pembicara dari sistem sendiri. Case study yang berguna adalah bukti, bukan resep universal.
- Tanyakan trade-off. “Kapan Anda tidak akan memakai ini?” sering lebih membuka wawasan daripada “Tool mana yang terbaik?”
- Catat satu tindak lanjut. Sebuah catatan lebih berguna jika menunjuk pada sesuatu yang perlu diverifikasi, diuji, atau dibaca setelah meetup.
- Jangan samakan talk yang meyakinkan dengan bukti production. Keputusan arsitektur, deployment, dan performa tetap harus divalidasi di lingkungan sendiri.
Apa yang tetap saya ingat
Saya tidak ingin melebih-lebihkan perubahan yang bisa dihasilkan satu meetup. Saya tidak pulang dari PiterJS dengan resep arsitektur universal, dan talk yang bagus tidak menggantikan dokumentasi, profiling, testing, atau data production.
Yang benar-benar saya bawa pulang lebih konkret: catatan berguna tentang modernisasi monolit legacy, FrontOps dengan Docker, dan pengukuran performa web; dua hadiah dari Q&A; serta pengingat lain bahwa komunitas developer lokal layak didatangi secara langsung.
Rekaman bisa menyimpan presentasinya. Bagian yang paling sulit diarsipkan adalah percakapan di sekelilingnya.