Bagaimana Braze Memerlukan JS dan Memodernisasi Tumpukan Teknologi Front-End Kami

Diterbitkan: 2021-09-24

Bagi ribuan pemasar di seluruh dunia, dasbor Braze adalah tempat mereka mewujudkan sesuatu. Pekerjaan yang terlibat dalam memastikan bahwa antarmuka ini adalah yang terbaik dilakukan oleh berbagai macam orang yang berbeda, dari desainer produk hingga insinyur. Dan meskipun pengoptimalan ini sering tentang antarmuka pengguna, pengoptimalan ini juga sering tentang teknologi yang mendukung dasbor.

Dalam beberapa tahun terakhir, salah satu perubahan paling signifikan di area ini adalah penghentian RequireJS dan migrasi dasbor ke Webpack , sebuah upaya yang dipelopori oleh Insinyur Perangkat Lunak Senior Braze Alex Guerra. Mari kita lihat kontribusi penting Guerra untuk proyek ini, seluk beluk proses migrasi, dan bagaimana peningkatan kecepatan selanjutnya membuatnya lebih mudah untuk memecahkan masalah pengkodean yang terkait dengan dasbor.

Dari Hack Day hingga Migrasi: Bagaimana Semuanya Dimulai

Ini lucu untuk dikatakan, tetapi saya akhirnya mengerjakan proyek penghentian RequireJS hampir secara tidak sengaja. Saya telah bekerja di tim Perpesanan dan Otomasi Braze Engineering selama sekitar delapan belas bulan, sebuah tim yang berfokus pada pengoptimalan jalur pengiriman pesan back-end untuk produk inti kami. Pada titik tertentu, saya bertanya kepada anggota tim lain tentang cara kerja ujung depan—dan meskipun dia memiliki gagasan yang kabur tentang hal itu, dia tidak mengetahui detail persisnya.

Itu membuatku penasaran; Saya benar-benar ingin memahami cara kerja dasbor kami. Dan karena Braze mengadakan hari retasan yang memungkinkan karyawan untuk mengejar proyek yang menarik, saya memutuskan untuk memanfaatkan hari retasan berikutnya untuk menjelajahi seluk beluk dasbor kami dengan memetakan dan mendokumentasikan kode front-end. Sekitar waktu yang sama, tim dasbor Braze telah mempertimbangkan untuk beralih dari RequireJS ke Webpack, yang diharapkan menjadi upaya besar. Tetapi selama penjelajahan saya, saya mulai melihat jalan ke depan yang saya pikir dapat membantu tim dasbor mengotomatiskan beberapa pekerjaan yang terlibat dalam meningkatkan perangkat lunak yang mendukung ujung depan platform Braze.

Tetapi untuk mendapatkan gambaran lengkap tentang apa yang ingin kami ubah dan mengapa saya begitu bersemangat, Anda harus memahami perbedaan antara RequireJS dan Webpack.

Mengembangkan Dasbor Braze: RequireJS vs. Webpack

Jadi, apa sih dasbor Braze itu? Pada tingkat paling dasar, ini adalah aplikasi JavaScript satu halaman. Dan ketika pemasar mengunjungi situs web Braze dan masuk ke platform kami, tampilan web yang mereka terima umumnya diinformasikan oleh versi paket kode dasbor. Bundel ini, yang mengumpulkan file berbeda untuk produksi, memiliki beberapa pengoptimalan berbeda yang diterapkan untuk membantu fungsi dasbor lebih efisien, termasuk:

  • Minifikasi untuk memungkinkannya memuat lebih cepat

  • Modifikasi kode otomatis yang memungkinkan dasbor beradaptasi dengan berbagai browser web

  • Pemisahan kode untuk memungkinkan kode front-end dimuat sesuai permintaan sesuai kebutuhan

Di Braze, proses bundling aset untuk kode JavaScript kami awalnya didukung oleh RequireJS, file JavaScript dan pemuat modul yang dirancang untuk penggunaan web. Namun seiring waktu, konsensus tumbuh dengan organisasi Produk dan Teknik Braze bahwa kami perlu mengembangkan cara kami menggabungkan kode untuk dasbor.

Faktor motivasi terbesar adalah kebutuhan untuk mempercepat proses pembangunan. Pengembang umumnya harus melalui proses pembuatan setiap kali mereka ingin memvalidasi perubahan yang mereka buat pada sepotong kode, untuk memastikan bahwa penyesuaian mereka memengaruhi perangkat lunak seperti yang mereka harapkan. Setelah jelas bahwa Webpack—bundel modul JavaScript open source—dapat melakukan pembangunan yang rumit ini lebih cepat dan efektif daripada RequireJS, kami tahu sudah waktunya untuk beralih.

Secara khusus, kami merasa bahwa membuat perubahan akan memiliki tiga manfaat utama:

1. Basis Kode Terpadu

Pada saat itu, ujung depan dasbor pada dasarnya terbelah menjadi dua, dengan satu setengah ditulis dalam CoffeeScript dan dibuat menggunakan RequireJS, sementara yang lainnya ditulis dalam JavaScript dan TypeScript dan dibuat dengan Webpack. Seperti yang Anda duga, berbagi kode di seluruh bagian adalah masalah dan dalam banyak kasus dibutuhkan beberapa peretasan yang sangat rapuh untuk membuat semuanya berfungsi. Jadi satu keuntungan utama dari melakukan pekerjaan yang terlibat dalam migrasi ke satu proses adalah bahwa hal itu memberikan peluang emas untuk benar-benar menyatukan—dan memodernisasi—basis kode.

2. Siklus Umpan Balik Lebih Pendek

Seperti yang saya sebutkan di atas, salah satu prioritas besar yang terkait dengan proyek ini adalah menemukan cara untuk mempersingkat siklus umpan balik bagi para insinyur yang bekerja di dasbor. Saat itu, jika Anda membuat modifikasi pada kode ujung depan, proses bundling dengan RequireJS akan memakan waktu rata-rata tiga menit—dan terkadang bisa memakan waktu hingga delapan menit. Itu waktu yang lama untuk membuat seorang insinyur menunggu untuk mengetahui apakah kode mereka beroperasi secara normal. Dengan Webpack, ada waktu mulai awal yang berlangsung sekitar 90 detik, tetapi setiap perubahan tambahan dapat dilakukan secara signifikan lebih cepat, memungkinkan para insinyur memanfaatkan waktu mereka dengan lebih baik dan menyelesaikan lebih banyak pekerjaan.

3. Pemecahan Masalah Lebih Efektif

Menemukan dan mengatasi kesalahan kode adalah bagian penting dari pekerjaan tim teknik mana pun. Di Braze, kami menggunakan produk bernama Sentry yang membantu mengatur dan melacak sumber masalah saat muncul di dasbor produksi. Tetapi karena kode itu adalah CoffeeScript yang dibuat dengan RequireJS, ketika dikompilasi dan diperkecil, nama deskriptif fungsi seperti "navigateToPill" akan diganti namanya menjadi sesuatu seperti "a." Itu, pada gilirannya, berarti bahwa kita akan melihat kesalahan ketik di "a" pada baris satu, kolom 200.000—yang, seperti yang Anda bayangkan, membuat banyak pekerjaan untuk menentukan sumber kesalahan itu. Webpack, di sisi lain, memiliki alat yang disebut Peta Sumber yang memungkinkan tim untuk mengambil kode yang diperkecil itu dan memetakan kolom dan baris tertentu ke file sumber; itu berarti Anda akan mendapatkan laporan Sentry yang mengatakan bahwa "navigateToPill" memiliki kesalahan pada baris tertentu, membuatnya lebih mudah untuk menyelesaikan masalah dengan lebih cepat.

Proses Migrasi: Pindah dari RequireJS ke Webpack

Kebutuhan untuk beralih dari RequireJS ke Webpack sudah jelas, tetapi skala usaha berarti bahwa mereka mengharapkan proses tersebut memakan waktu setidaknya satu tahun dan melibatkan banyak kerumitan dan bandwidth rekayasa untuk dicapai. Pikiran pada saat itu adalah bahwa kami harus secara sistematis menelusuri basis kode bagian demi bagian dan memigrasikan semuanya secara manual, yang akan sangat memberatkan.

Terobosan saya, jika Anda ingin menyebutnya begitu, adalah menyadari bahwa saya dapat menulis kode yang mampu mengubah kode dasbor Braze secara massal melalui proses otomatis—dan juga tidak mengubah kode kami, jika kami perlu memutar kembali perubahan ini dengan cepat. Saya akhirnya melakukan pembuktian konsep setelah proyek hack day saya, hanya untuk menunjukkan bahwa itu bisa berhasil, dan kemudian terus mengerjakannya di waktu luang saya sebagai semacam proyek gairah.

Yang mengatakan, hal-hal tidak benar-benar lepas landas sampai Greg Beaver—yang merupakan Insinyur Perangkat Lunak Senior di tim Dasbor Braze—terlibat. Dia mampu mengambil skrip yang saya tulis sebagai bagian dari bukti konsep saya dan memasukkannya ke dalam alat yang dapat kami bagikan dengan insinyur lain. Itu, pada gilirannya, berarti kami dapat bermigrasi dari RequireJS ke Webpack tanpa memaksa semua insinyur yang mengerjakan kode yang terkait dengan dasbor untuk berhenti saat kami melakukannya; sebagai gantinya, mereka dapat menggunakan alat ini untuk secara otomatis membawa kode apa pun yang sedang mereka kerjakan selaras dengan perubahan keseluruhan.

Alat tersebut menjadi sangat cepat—hanya membutuhkan waktu sekitar dua menit untuk berjalan—dan bekerja dengan sangat baik sehingga saat kami membuat persiapan untuk migrasi, kami sebenarnya memiliki seorang insinyur yang memanfaatkannya sebagai solusi untuk pembangunan lambat yang terkait dengan RequireJS. Mereka baru saja mengonversi cabang mereka ke Webpack, membuat perubahan yang perlu mereka buat, dan kemudian mengonversinya kembali sehingga mereka bisa mengkomitnya dalam kode lama.

Dengan kemampuan baru yang kami miliki, rencana migrasi kami adalah menjalankan alat Greg di cabang utama kami setiap malam selama beberapa minggu dan membuat orang meninjau secara manual di lingkungan QA dari cabang itu, hanya untuk melihat apakah ada yang rusak. Setelah kami yakin bahwa semuanya tampak baik, kami memberi tahu seluruh organisasi tentang pembaruan yang direncanakan, memandu mereka melalui bagaimana mereka dapat memigrasikan kode mereka dari RequireJS ke Webpack, dan memberi mereka petunjuk tentang beberapa pertimbangan utama sebelum mereka mendapatkannya. berlangsung.

Berkat pendekatan kami, sebuah proyek yang diperkirakan akan memakan waktu lebih dari satu tahun akhirnya diselesaikan hanya dalam tiga minggu, yang sangat luar biasa. Yang lebih tidak terduga adalah dampak migrasi—khususnya, proses pembuatan di Webpack sekarang umumnya hanya membutuhkan waktu sekitar satu detik, mengurangi waktu yang diperlukan untuk setiap pemeriksaan kode hingga lebih dari 99%.

Di Braze, kami berkomitmen untuk membangun lingkungan tempat individu seperti Guerra dapat memanfaatkan perspektif dan bakat unik mereka sebaik mungkin. Apakah Anda seseorang yang ingin mendorong batas dan membayangkan kembali apa yang mungkin? Lihat halaman karir kami untuk mempelajari lebih lanjut tentang posisi terbuka kami.