Wie Braze RequireJS aufgegeben und unseren Front-End-Tech-Stack modernisiert hat

Vom Hack Day bis zur Migration: Wie alles begann

Es ist lustig zu sagen, aber ich habe fast zufällig am RequireJS-Verwerfungsprojekt mitgearbeitet. Ich arbeite seit etwa 18 Monaten im Messaging and Automation Team von Braze Engineering, einem Team, das sich auf die Optimierung der Back-End-Pipeline zum Versenden von Nachrichten für unser Kernprodukt konzentriert. Irgendwann habe ich ein anderes Teammitglied gefragt, wie das Frontend funktioniert – und obwohl er eine vage Vorstellung davon hatte, waren ihm die genauen Details nicht klar.

Das hat mich neugierig gemacht; Ich wollte unbedingt verstehen, wie unser Dashboard funktioniert. Und weil Braze Hack-Days veranstaltet, an denen Mitarbeiter Leidenschaftsprojekte verfolgen können, habe ich beschlossen, den nächsten Hack-Day zu nutzen, um die Einzelheiten unseres Dashboards zu erkunden, indem ich den Front-End-Code entwerfe und dokumentiere. Etwa zur gleichen Zeit hatte das Braze-Dashboard-Team den Wechsel von RequireJS zu Webpack in Betracht gezogen, was ein großes Unterfangen werden sollte. Aber im Laufe meiner Erkundung begann ich, einen Weg nach vorne zu sehen, von dem ich dachte, dass er dem Dashboard-Team helfen könnte, einen Teil der Arbeit zu automatisieren, die mit der Aktualisierung der Software verbunden ist, die das Front-End der Braze-Plattform unterstützt.

Aber um ein vollständiges Bild davon zu bekommen, was wir ändern wollten und warum ich davon so begeistert war, müssen Sie die Unterschiede zwischen RequireJS und Webpack verstehen.

Weiterentwicklung des Braze-Dashboards: RequireJS vs. Webpack

Also, was ist überhaupt das Braze-Dashboard? Auf der einfachsten Ebene ist es eine einseitige JavaScript-Anwendung. Und wenn ein Vermarkter die Braze-Website besucht und sich bei unserer Plattform anmeldet, wird die Webansicht, die er erhält, im Allgemeinen durch eine gebündelte Version des Dashboard-Codes informiert. Auf dieses Paket, das unterschiedliche Dateien für die Produktion sammelt, wurden mehrere verschiedene Optimierungen angewendet, die dazu beitragen, dass das Dashboard effizienter funktioniert, darunter:

• Verkleinerung, damit es schneller geladen werden kann

• Automatische Codeänderungen, mit denen sich das Dashboard an verschiedene Webbrowser anpassen lässt

• Code-Splitting, damit Front-End-Code bei Bedarf geladen werden kann

Bei Braze wurde dieser Asset-Bündelungsprozess für unseren JavaScript-Code ursprünglich von RequireJS unterstützt, einem JavaScript-Datei- und Modullader, der für die Verwendung im Internet entwickelt wurde. Aber im Laufe der Zeit wuchs ein Konsens mit der Braze Product and Engineering-Organisation, dass wir die Art und Weise, wie wir Code für das Dashboard bündelten, weiterentwickeln mussten.

Der größte Motivationsfaktor war die Notwendigkeit, den Build-Prozess zu beschleunigen. Ein Entwickler muss im Allgemeinen den Build-Prozess jedes Mal durchlaufen, wenn er die Änderungen validieren möchte, die er an einem Codeabschnitt vorgenommen hat, um sicherzustellen, dass sich seine Anpassungen wie erwartet auf die Software auswirken. Als klar war, dass Webpack – ein Open-Source-JavaScript-Modul-Bundler – diese komplizierten Builds schneller und effektiver ausführen konnte als RequireJS, wussten wir, dass es an der Zeit war, umzusteigen.

Insbesondere waren wir der Meinung, dass eine Änderung drei wesentliche Vorteile hätte:

1. Eine einheitliche Codebasis

Zu diesem Zeitpunkt war das Frontend des Dashboards im Wesentlichen zweigeteilt, wobei die eine Hälfte in CoffeeScript geschrieben und mit RequireJS erstellt wurde, während die andere in JavaScript und TypeScript geschrieben und mit Webpack erstellt wurde. Wie zu erwarten war, war das Teilen von Code über die Kluft hinweg ein Problem, und in vielen Fällen waren einige sehr spröde Hacks erforderlich, damit alles funktionierte. Ein großer Vorteil der Arbeit, die mit der Migration zu einem einzigen Prozess verbunden war, bestand also darin, dass dies eine einmalige Gelegenheit bot, die Codebasis wirklich zu vereinheitlichen – und zu modernisieren.

2. Kürzere Feedbackzyklen

Wie ich oben erwähnt habe, war eine der großen Prioritäten im Zusammenhang mit diesem Projekt, Wege zu finden, um den Feedback-Zyklus für Ingenieure zu verkürzen, die am Dashboard arbeiten. Wenn Sie damals eine Änderung am Frontend-Code vorgenommen haben, dauerte der Bündelungsprozess mit RequireJS durchschnittlich drei Minuten – und manchmal konnte es bis zu acht Minuten dauern. Das ist eine lange Zeit, um einen Ingenieur warten zu lassen, um herauszufinden, ob sein Code normal funktioniert. Bei Webpack beträgt die anfängliche Startzeit etwa 90 Sekunden, aber jede weitere Änderung kann erheblich schneller durchgeführt werden, sodass Ingenieure ihre Zeit besser nutzen und mehr erledigen können.

3. Effektivere Fehlerbehebung

Das Finden und Beheben von Codefehlern ist ein wesentlicher Bestandteil der Arbeit eines jeden Engineering-Teams. Bei Braze verwenden wir ein Produkt namens Sentry, das hilft, die Ursache von Problemen zu organisieren und zu verfolgen, wenn sie im Produktions-Dashboard auftauchen. Da es sich bei diesem Code jedoch um CoffeeScript handelte, das mit RequireJS erstellt wurde, wurde der beschreibende Name einer Funktion wie „navigateToPill“ beim Kompilieren und Minimieren in etwas wie „a“ umbenannt. Das wiederum bedeutete, dass wir einen Tippfehler in „a“ in Zeile eins, Spalte 200.000 sehen würden – was, wie Sie sich vorstellen können, eine Menge Arbeit machte, um die Quelle dieses Fehlers zu ermitteln. Webpack hingegen verfügt über ein Tool namens Source Maps, mit dem Teams diesen minimierten Code nehmen und eine bestimmte Spalte und Zeile der Quelldatei zuordnen können. Das bedeutet, dass Sie Sentry-Berichte erhalten, die besagen, dass „navigateToPill“ einen Fehler in einer bestimmten Zeile hatte, was es einfacher macht, Probleme schneller zu lösen.

Der Migrationsprozess: Wechsel von RequireJS zu Webpack

Die Notwendigkeit, von RequireJS zu Webpack zu wechseln, war klar, aber der Umfang des Unterfangens bedeutete, dass sie davon ausgingen, dass der Prozess mindestens ein Jahr dauern und viel Komplexität und technische Bandbreite erfordern würde. Die damalige Überlegung war, dass wir die Codebasis systematisch Abschnitt für Abschnitt durchgehen und alles manuell migrieren müssten, was wirklich mühsam gewesen wäre.

Mein Durchbruch, wenn Sie es so nennen wollen, war die Erkenntnis, dass ich Code schreiben konnte, der in der Lage war, den Code des Braze-Dashboards in großen Mengen durch einen automatisierten Prozess zu ändern – und auch unseren Code rückgängig zu machen, wenn wir diese Änderungen rückgängig machen mussten schnell. Am Ende habe ich nach meinem Hack-Day-Projekt einen Proof of Concept erstellt, nur um zu zeigen, dass es funktionieren könnte, und dann in meiner Freizeit als eine Art Leidenschaftsprojekt weiter daran gearbeitet.

Das heißt, die Dinge nahmen nicht wirklich Fahrt auf, bis Greg Beaver – ein Senior Software Engineer im Braze Dashboard-Team – sich einmischte. Er konnte die Skripte, die ich als Teil meines Proof of Concept geschrieben hatte, in ein Tool integrieren, das wir mit anderen Ingenieuren teilen konnten. Das wiederum bedeutete, dass wir von RequireJS zu Webpack migrieren konnten, ohne dass alle Ingenieure, die an Code im Zusammenhang mit dem Dashboard arbeiteten, währenddessen anhalten mussten. Stattdessen konnten sie das Tool verwenden, um jeden Code, an dem sie arbeiteten, automatisch mit den allgemeinen Änderungen zu synchronisieren.

Das Tool war so schnell – es dauerte nur etwa zwei Minuten – und funktionierte so gut, dass es während der Vorbereitungen für die Migrationen tatsächlich von einem Techniker als Workaround für die langsamen Builds im Zusammenhang mit RequireJS genutzt wurde. Sie haben einfach ihren Branch auf Webpack umgestellt, die erforderlichen Änderungen vorgenommen und sie dann wieder zurückkonvertiert, damit sie sie im alten Code festschreiben konnten.

Mit dieser neuen Funktion, die uns zur Verfügung stand, bestand unser Migrationsplan darin, Gregs Tool einige Wochen lang jede Nacht auf unserem Hauptzweig auszuführen und die Leute dazu zu bringen, die QA-Umgebung dieses Zweigs manuell zu überprüfen, nur um zu sehen, ob etwas kaputt war. Als wir sicher waren, dass alles gut aussah, informierten wir den Rest der Organisation über das geplante Update, führten sie durch, wie sie ihren Code von RequireJS zu Webpack migrieren konnten, und gaben ihnen eine Vorwarnung zu einigen wichtigen Überlegungen, bevor sie es bekamen unterwegs.

Dank unseres Ansatzes wurde ein Projekt, das über ein Jahr dauern sollte, in nur drei Wochen abgeschlossen, was ziemlich unglaublich ist. Noch unerwarteter waren die Auswirkungen der Migration – insbesondere dauert der Build-Prozess auf Webpack jetzt im Allgemeinen nur etwa eine Sekunde, wodurch die für jede Codeprüfung benötigte Zeit um mehr als 99 % reduziert wird.

Bei Braze setzen wir uns dafür ein, ein Umfeld zu schaffen, in dem Personen wie Guerra ihre einzigartigen Perspektiven und Talente optimal nutzen können. Sind Sie jemand, der Grenzen überschreiten und das Mögliche neu erfinden möchte? Besuchen Sie unsere Karriereseite , um mehr über unsere offenen Stellen zu erfahren.