Come Braze ha deprecato RequireJS e ha modernizzato il nostro stack tecnologico front-end

Dall'hacking alla migrazione: come è iniziato tutto

È divertente da dire, ma ho finito per lavorare al progetto di deprecazione di RequireJS quasi per caso. Ho lavorato nel team di messaggistica e automazione di Braze Engineering per circa diciotto mesi, un team concentrato sull'ottimizzazione della pipeline di invio di messaggi back-end per il nostro prodotto principale. Ad un certo punto, ho chiesto a un altro membro del team come funzionava il front-end e, sebbene ne avesse una vaga idea, non era chiaro sui dettagli esatti.

Questo mi ha incuriosito; Volevo davvero capire come funzionava la nostra dashboard. E poiché Braze organizza giornate di hack che consentono ai dipendenti di perseguire progetti di passione, ho deciso di sfruttare il giorno di hack successivo per esplorare i dettagli della nostra dashboard mappando e documentando il codice front-end. Più o meno nello stesso periodo, il team del dashboard di Braze stava cercando di passare da RequireJS a Webpack, che avrebbe dovuto essere un'impresa importante. Ma nel corso della mia esplorazione, ho iniziato a vedere un percorso in avanti che pensavo potesse aiutare il team del dashboard ad automatizzare parte del lavoro coinvolto nell'aggiornamento del software a supporto del front-end della piattaforma Braze.

Ma per avere un quadro completo di ciò che stavamo cercando di cambiare e del motivo per cui ne sono così entusiasta, devi capire le differenze tra RequireJS e Webpack.

Evoluzione del dashboard di Braze: RequireJS vs. Webpack

Quindi, qual è il dashboard Braze, comunque? Al livello più elementare, è un'applicazione JavaScript a pagina singola. E quando un marketer visita il sito Web di Braze e accede alla nostra piattaforma, la visualizzazione Web che riceve è generalmente informata da una versione in bundle del codice della dashboard. Questo pacchetto, che raccoglie file disparati per la produzione, ha diverse ottimizzazioni applicate che aiutano il dashboard a funzionare in modo più efficiente, tra cui:

• Minimizzazione per consentirgli di caricarsi più velocemente

• Modifiche automatiche del codice che consentono alla dashboard di adattarsi a diversi browser web

• Suddivisione del codice per consentire il caricamento del codice front-end su richiesta in base alle esigenze

In Braze, il processo di raggruppamento delle risorse per il nostro codice JavaScript era originariamente supportato da RequireJS, un file JavaScript e un caricatore di moduli progettato per l'uso sul Web. Ma nel tempo è cresciuto un consenso con l'organizzazione Braze Product and Engineering sulla necessità di evolvere il modo in cui raggruppavamo il codice per la dashboard.

Il più grande fattore motivante è stata la necessità di accelerare il processo di costruzione. Uno sviluppatore in genere deve eseguire il processo di compilazione ogni volta che desidera convalidare le modifiche apportate a un pezzo di codice, per assicurarsi che la loro regolazione influisca sul software nel modo previsto. Una volta che è stato chiaro che Webpack, un bundler di moduli JavaScript open source, poteva eseguire queste complicate build in modo più rapido ed efficace di RequireJS, abbiamo capito che era giunto il momento di passare.

In particolare, abbiamo ritenuto che apportare la modifica avrebbe avuto tre vantaggi chiave:

1. Una base di codice unificata

A quel punto, il front-end della dashboard era essenzialmente diviso in due, con una metà scritta in CoffeeScript e costruita utilizzando RequireJS, mentre l'altra era scritta in JavaScript e TypeScript e costruita con Webpack. Come ci si potrebbe aspettare, la condivisione del codice attraverso il divario era un problema e in molti casi sono stati necessari alcuni hack molto fragili per far funzionare tutto. Quindi uno dei principali vantaggi del lavoro coinvolto nella migrazione a un singolo processo è stato che ha rappresentato un'opportunità d'oro per unificare e modernizzare veramente la base di codice.

2. Cicli di feedback più brevi

Come accennato in precedenza, una delle grandi priorità associate a questo progetto era trovare modi per abbreviare il ciclo di feedback per gli ingegneri che lavoravano sulla dashboard. All'epoca, se si apportava una modifica al codice front-end, il processo di raggruppamento con RequireJS richiedeva in media tre minuti e talvolta fino a otto minuti. È molto tempo per far aspettare un ingegnere per scoprire se il loro codice funziona normalmente. Con Webpack, c'è un tempo di avvio iniziale che dura circa 90 secondi, ma ogni modifica aggiuntiva può essere eseguita molto più velocemente, consentendo agli ingegneri di utilizzare meglio il loro tempo e ottenere di più.

3. Risoluzione dei problemi più efficace

Trovare e risolvere gli errori di codice è una parte essenziale del lavoro di qualsiasi team di ingegneri. In Braze, utilizziamo un prodotto chiamato Sentry che aiuta a organizzare e rintracciare l'origine dei problemi quando emergono nella dashboard di produzione. Ma poiché quel codice è stato creato da CoffeeScript con RequireJS, quando è stato compilato e minimizzato, il nome descrittivo di una funzione come "navigateToPill" sarebbe stato rinominato in qualcosa come "a". Ciò, a sua volta, significava che avremmo visto un errore di tipo in "a" sulla prima riga, colonna 200.000, il che, come puoi immaginare, ha reso molto lavoro per determinare l'origine di quell'errore. Webpack, d'altra parte, ha uno strumento chiamato Source Maps che consente ai team di prendere quel codice ridotto e mappare una determinata colonna e riga al file sorgente; ciò significa che otterresti rapporti Sentry che dicono che "navigateToPill" ha avuto un errore su una riga specifica, rendendo più facile risolvere i problemi più velocemente.

Il processo di migrazione: passaggio da RequireJS a Webpack

La necessità di passare da RequireJS a Webpack era chiara, ma la portata dell'impresa significava che si aspettavano che il processo richiedesse almeno un anno e richiedesse molta complessità e larghezza di banda ingegneristica da raggiungere. Il pensiero all'epoca era che avremmo dovuto esaminare sistematicamente la base di codice sezione per sezione e migrare manualmente tutto, il che sarebbe stato davvero oneroso.

La mia svolta, se così si può chiamare, è stata capire che potevo scrivere codice in grado di modificare in blocco il codice della dashboard di Braze attraverso un processo automatizzato e anche annullare la modifica del nostro codice, se avessimo bisogno di annullare queste modifiche velocemente. Ho finito per fare un proof of concept dopo il mio progetto hack day, solo per dimostrare che poteva funzionare, e poi ho continuato a lavorarci nel mio tempo libero come una sorta di progetto di passione.

Detto questo, le cose non sono davvero decollate fino a quando Greg Beaver, che è un Senior Software Engineer nel team di Braze Dashboard, non è stato coinvolto. È stato in grado di prendere gli script che avevo scritto come parte del mio proof of concept e incorporarli in uno strumento che potevamo condividere con altri ingegneri. Ciò, a sua volta, significava che avremmo potuto migrare da RequireJS a Webpack senza costringere tutti gli ingegneri che lavoravano al codice relativo al dashboard a fermarsi mentre lo facevamo; invece, sono stati in grado di utilizzare lo strumento per sincronizzare automaticamente qualsiasi codice su cui stavano lavorando con le modifiche complessive.

Lo strumento ha finito per essere così veloce (l'esecuzione richiede solo due minuti circa) e ha funzionato così bene che mentre stavamo preparando le migrazioni, in realtà abbiamo avuto un ingegnere che lo sfruttava come soluzione alternativa per le build lente associate a RequireJS. Hanno appena convertito il loro ramo in Webpack, hanno apportato le modifiche necessarie e quindi lo hanno riconvertito in modo da poterlo eseguire nel vecchio codice.

Con questa nuova funzionalità a nostra disposizione, il nostro piano di migrazione prevedeva di eseguire lo strumento di Greg sul nostro ramo principale ogni notte per alcune settimane e convincere le persone a rivedere manualmente nell'ambiente di QA da quel ramo, solo per vedere se qualcosa non funzionava. Una volta che siamo stati certi che tutto fosse a posto, abbiamo informato il resto dell'organizzazione sull'aggiornamento pianificato, li abbiamo guidati attraverso come potevano migrare il loro codice da RequireJS a Webpack e li abbiamo informati su alcune considerazioni chiave prima che ottenessero in corso.

Grazie al nostro approccio, un progetto che avrebbe dovuto durare più di un anno è finito per essere concluso in sole tre settimane, il che è piuttosto incredibile. Ancora più inaspettato è stato l'impatto della migrazione: in particolare, il processo di compilazione su Webpack ora richiede generalmente solo circa un secondo, riducendo il tempo necessario per ogni controllo del codice di oltre il 99%.

In Braze, ci impegniamo a costruire un ambiente in cui individui come Guerra possano sfruttare al meglio le loro prospettive e talenti unici. Sei qualcuno che cerca di superare i limiti e reimmaginare ciò che è possibile? Dai un'occhiata alla nostra pagina delle carriere per saperne di più sulle nostre posizioni aperte.