Braze 如何棄用 RequireJS 並使我們的前端技術堆棧現代化

已發表: 2021-09-24

對於全球成千上萬的營銷人員來說,Braze 儀表板是他們讓事情發生的地方。 確保該界面處於最佳狀態所涉及的工作由從產品設計師到工程師的各種不同的人承擔。 雖然這些優化通常與用戶界面有關,但同樣常見的是,它們與支持儀表板的技術有關。

近年來,該領域最重要的轉變之一是我們棄用了RequireJS並將儀表板遷移到Webpack ,這是由 Braze 高級軟件工程師 Alex Guerra 帶頭的一項工作。 讓我們來看看 Guerra 對這個項目的重要貢獻,遷移過程的來龍去脈,以及隨後的速度改進如何使解決與儀表板相關的編碼問題變得更加容易。

從黑客日到遷移:一切是如何開始的

說起來很有趣,但我最終幾乎是偶然地參與了 RequireJS deprecation 項目。 我在 Braze Engineering 的消息傳遞和自動化團隊工作了大約 18 個月,該團隊專注於優化我們核心產品的後端消息發送管道。 在某個時候,我問過另一個團隊成員前端是如何工作的——雖然他對此有一個模糊的概念,但他並不清楚具體的細節。

這讓我很好奇; 我真的很想了解我們的儀表板是如何工作的。 而且因為 Braze 舉辦了允許員工追求激情項目的黑客日,我決定利用下一個黑客日通過繪製和記錄前端代碼來探索我們儀表板的細節。 大約在同一時間,Braze 儀表板團隊一直在考慮從 RequireJS 切換到 Webpack,預計這將是一項重大任務。 但是在我的探索過程中,我開始看到一條前進的道路,我認為可以幫助儀表板團隊自動化升級支持 Braze 平台前端的軟件所涉及的一些工作。

但是要全面了解我們希望改變的內容以及為什麼我對它如此興奮,您必須了解 RequireJS 和 Webpack 之間的區別。

改進 Braze 儀表板:RequireJS 與 Webpack

那麼,Braze 儀表板到底是什麼? 在最基本的層面上,它是一個單頁 JavaScript 應用程序。 當營銷人員訪問 Braze 網站並登錄我們的平台時,他們收到的 Web 視圖通常由儀表板代碼的捆綁版本通知。 該捆綁包收集了用於生產的不同文件,並對其應用了幾種不同的優化,以幫助儀表板更有效地運行,包括:

  • 縮小以使其加載更快

  • 自動代碼修改,讓儀表板適應不同的網絡瀏覽器

  • 代碼拆分以允許前端代碼按需加載

在 Braze,我們的 JavaScript 代碼的資產捆綁過程最初是由 RequireJS 支持的,RequireJS 是一個專為 Web 使用而設計的 JavaScript 文件和模塊加載器。 但隨著時間的推移,Braze 產品和工程組織達成了共識,即我們需要改進為儀表板捆綁代碼的方式。

最大的激勵因素是需要加快構建過程。 開發人員每次想要驗證他們對一段代碼所做的更改時,通常都需要完成構建過程,以確保他們的調整以他們期望的方式影響軟件。 一旦明確 Webpack(一個開源 JavaScript 模塊捆綁器)可以比 RequireJS 更快、更有效地執行這些複雜的構建,我們就知道是時候做出改變了。

特別是,我們認為進行更改將具有三個主要好處:

1. 統一的代碼庫

那時,儀表板的前端基本上一分為二,一半是用 CoffeeScript 編寫並使用 RequireJS 構建的,另一半是用 JavaScript 和 TypeScript 編寫並使用 Webpack 構建的。 正如您所料,跨界共享代碼是一個問題,並且在很多情況下,需要一些非常脆弱的黑客才能使其全部工作。 因此,遷移到單個流程所涉及的工作的一個主要好處是,它提供了一個真正統一和現代化代碼庫的黃金機會。

2. 更短的反饋週期

正如我上面提到的,與該項目相關的一大優先事項是尋找方法來縮短在儀表板上工作的工程師的反饋週期。 那時,如果您對前端代碼進行修改,與 RequireJS 的捆綁過程平均需要 3 分鐘,有時甚至可能長達 8 分鐘。 這讓工程師等待找出他們的代碼是否正常運行需要很長時間。 使用 Webpack,初始啟動時間大約為 90 秒,但每次額外的更改都可以顯著加快,從而使工程師能夠更好地利用他們的時間並完成更多工作。

3. 更有效的故障排除

查找和解決代碼錯誤是任何工程團隊工作的重要組成部分。 在 Braze,我們使用一種名為 Sentry 的產品,當問題出現在生產儀表板中時,它可以幫助組織和追踪問題的根源。 但是因為該代碼是使用 RequireJS 構建的 CoffeeScript,所以當它被編譯和縮小時,像“navigateToPill”這樣的函數的描述性名稱將被重命名為“a”。 反過來,這意味著我們會在第一行第 200,000 列的“a”中看到一個類型錯誤——正如您想像的那樣,這使得確定該錯誤的來源需要做很多工作。 另一方面,Webpack 有一個名為 Source Maps 的工具,它允許團隊獲取縮小的代碼並將給定的列和行映射到源文件; 這意味著您會收到 Sentry 報告說“navigateToPill”在特定行有錯誤,從而更容易更快地解決問題。

遷移過程:從 RequireJS 遷移到 Webpack

從 RequireJS 切換到 Webpack 的必要性很明顯,但這項工作的規模意味著他們預計該過程至少需要一年時間,並且需要大量複雜性和工程帶寬才能實現。 當時的想法是,我們將不得不繫統地逐節檢查代碼庫並手動遷移所有內容,這確實很繁重。

我的突破,如果你想這樣稱呼它,是意識到我可以編寫能夠通過自動化過程批量修改 Braze 儀表板代碼的代碼,並且如果我們需要回滾這些更改,也可以取消修改我們的代碼迅速地。 在我的黑客日項目之後,我最終做了一個概念驗證,只是為了證明它可以工作,然後在我的業餘時間繼續工作,作為一種激情項目。

也就是說,直到 Braze Dashboard 團隊的高級軟件工程師 Greg Beaver 參與進來,事情才真正開始。 他能夠將我編寫的腳本作為我概念驗證的一部分,並將它們整合到我們可以與其他工程師共享的工具中。 反過來,這意味著我們可以從 RequireJS 遷移到 Webpack,而不會迫使所有處理與儀表板相關的代碼的工程師在我們這樣做時停下來; 相反,他們能夠使用該工具自動將他們正在處理的任何代碼與整體更改同步。

該工具最終變得如此之快 - 只需大約兩分鐘即可運行 - 並且運行良好,以至於在我們為遷移做準備時,我們實際上讓工程師利用它作為與 RequireJS 相關的緩慢構建的解決方法。 他們只是將他們的分支轉換為 Webpack,進行了他們需要進行的更改,然後將其轉換回來,以便他們可以在舊代碼中提交它。

有了這個可供我們使用的新功能,我們的遷移計劃是每晚在我們的主分支上運行 Greg 的工具幾週,然後讓人們在該分支的 QA 環境中手動審查,看看是否有任何問題。 一旦我們確信一切看起來都不錯,我們就向組織的其他成員簡要介紹了計劃中的更新,引導他們了解如何將代碼從 RequireJS 遷移到 Webpack,並在他們得到之前提醒他們一些關鍵注意事項進行。

由於我們的方法,一個預計需要一年多的項目最終在短短三週內完成,這非常不可思議。 更出乎意料的是遷移的影響——尤其是現在 Webpack 上的構建過程通常只需要大約一秒鐘,將每次代碼檢查所需的時間減少了 99% 以上。

在 Braze,我們致力於營造一個環境,​​讓像 Guerra 這樣的人可以充分利用他們獨特的觀點和才能。 您是否正在尋求突破界限並重新構想可能的事情? 查看我們的職業頁面,了解更多關於我們的空缺職位的信息。