De PHP a Next.js: què va aprendre Trivago reescrivint la seva aplicació web

El servei de cerca d’hotels Trivago va reescriure la seva interfície en Typescript al marc Next.js, substituint una base de codi PHP en un marc de JavaScript local, Melody. Des d’abril de 2020 fins a finals de 2021, l’equip de la plataforma va crear, provar i desplegar la nova aplicació que va reduir la mida de la pàgina fins a un 37%, alhora que augmentava les publicacions diàries de codi.

L’enginyeria es tracta de compensacions, i Tom Bartel, Trivago Team Lead Interface Platform, fa un treball excel·lent il·lustrant els compromisos que van portar a la reescriptura de la plataforma a la seva recent publicació al bloc. Va ser una empresa massiva, sobretot quan res és inherentment “malament” o trencat amb la base de codi.

Què funcionava? Bé, el lloc en general ho era. Els usuaris estaven gaudint de totes les funcionalitats al web i al mòbil. Hi havia un equip d’enginyers format amb molts que gaudien de les seves tasques funcionals.

Què “no funcionava”? La melodia era de producció pròpia, així que no estava molt estesa. L’ecosistema era petit, la documentació era limitada i les aplicacions d’enginyeria (és a dir, Google i Stack Overflow) eren molt limitades o no ajudaven en absolut. Hi havia com a màxim dos mantenedors bàsics amb almenys un de guàrdia en tot moment. Va ser un repte incorporar nous empleats i alguns van expressar la seva preocupació perquè estaven aprenent i cultivant habilitats intransferibles.

Doblar a Melody? Assignar recursos per modernitzar el marc, actualitzar i afegir documentació de qualitat i formar enginyers per mantenir-los? O mira cap avall…

…La pàgina en blanc

No és un projecte nou, però sí un projecte nou. Atès que l’esforç, anomenat internament Web Application Rewrite Project (WARP), és una reescriptura completa i no un refactor, sorgeixen totes les preguntes del nou projecte:

  • Biblioteques: quins són els més atractius per a serveis públics, càlcul de dates, etc…?
  • Fitxers CSS: com organitzar-los?
  • Estat de l’aplicació: com es mantindrà?
  • Transmissió d’esdeveniments: com es farà?
  • Pàgines HTML: es generarà prèviament de manera estàtica?
  • Estructura: per a URL i pàgines.
  • Inicialització de l’aplicació: com funcionarà?
  • API de components: com serà el disseny?

Decisions, decisions!

Amb tantes decisions i l’equip treballant de manera remota (la col·laboració remota encara es considerava nova quan aquest projecte va començar l’abril de 2020), els enginyers de Trivago van implementar un enfocament increïblement metòdic i pragmàtic per abordar les qüestions d’enginyeria tàctil i, finalment, prendre decisions.

  • Document de decisió: aquest document recull i organitza els fets i punts de vista rellevants de l’enginyer.
  • Reunió de decisió: un lloc per a la discussió dels punts de vista que condueixen finalment a la decisió.
  • Propietari de la decisió: cura el document, prepara la reunió de decisió i s’assegura que es pren una decisió.

Algunes decisions van ser fàcils d’aconseguir, mentre que d’altres van ser difícils de guanyar, algunes van passar del document a la prova, mentre que d’altres es van refactoritzar perquè la implementació no va complir les expectatives originals.

Va ser durant la implementació d’una altra decisió que va semblar massa complicada per a alguns desenvolupadors que els enginyers de Trivago van decidir avançar amb Next.js i React.

Un gran consell que prové del procés de reescriptura d’assaig i error de Trivago és comprometre’s amb les decisions, però mantenir la ment oberta i corregir el curs quan sigui necessari. Les decisions preses amb els millors coneixements i intencions poden aportar noves idees durant la implementació.

Casi allà

Una vegada que la reescriptura va ser totalment funcional i útil per a l’usuari, es va exposar al món real i es va provar amb taulers de control, comprovacions i comparacions que servien de guies perquè els enginyers veiessin què necessitava atenció.

  • Interacció de l’usuari: Difereix això entre productes? Si és així, la causa va ser un error o alguna cosa més?
  • Tornat: La nova aplicació reenvia als llocs de reserves al mateix preu?
  • Tipus de cerca: Trivago ajusta automàticament els tipus de cerca per obtenir millors resultats. Per exemple, si una cerca és massa limitada, Trivago ampliarà els paràmetres i afegirà resultats. Un indicador directe que alguna cosa no funcionava és una diferència en els llistats. Això va provocar una investigació posterior.

funcionalitat del mapa

Va trigar diversos mesos d’enginyeria, però finalment, l’interruptor es va girar i tot el trànsit d’usuaris va anar a la nova aplicació.

Es van obtenir recompenses!

Beneficis per a l’usuari

El temps d’inici depèn en gran mesura de la mida del codi enviat per Trivago. Com que els enginyers depenen molt de biblioteques de codi obert com Next.js, Preact i react-use, observen de prop la mida del codi.

El nou producte va reduir el pes de la pàgina de 2,1 MB a 1,7 MB (19%) per a pàgines temàtiques i de 4,1 MB a 2,6 MB (37%) per a pàgines de resultats. Convertir l’aplicació d’una sola pàgina en diverses pàgines i utilitzar la funció de divisió automàtica de codi de Next.js va resultar ser molt beneficiós.

Com a resultat, Trivago ara funciona amb més facilitat amb un maquinari més feble. Android 6, que representa aproximadament el 0,5% de tots els clients d’Android, és el maquinari més feble que utilitza l’aplicació Trivago. Les seves proves mostren que l’aplicació funciona amb fluïdesa a Android 6.

Beneficis per a desenvolupadors

Aquest és un vincle sòlid amb el motiu pel qual va començar la reescriptura en primer lloc. Base de codi més neta amb documentació de qualitat i àmpliament disponible, tant interna com en termes d’ecosistema global disponible per cercar a google i Stack Overflow. Els nous desenvolupadors tenen més facilitat per incorporar-se i hi ha més sensació de familiaritat i habilitats transferibles per desenvolupar.

Les plataformes antigues versus les noves

No hi ha cap prova definitiva d’un desenvolupament més ràpid, les sol·licituds d’extracció fusionades mensuals són més altes a la nova base de codi (vegeu el gràfic anterior) amb el mateix nombre d’enginyers que hi havia treballant a la base freda més antiga.

Ara hi ha deu llançaments al dia en comparació amb els dos anteriors. Amb una mica més de neteja, els sistemes heretats addicionals s’apagaran, permetent així més recursos disponibles per a la nova aplicació.

En general, aquesta gran reescriptura té un cost i hi va haver moltes lluites, es van perdre ingressos, tot i que es van combinar bé amb la desacceleració dels viatges del 2020. L’equip d’enginyeria va créixer enormement en termes d’habilitats d’enginyeria i habilitats suaus.

Tenint en compte tots els contratemps, el projecte va ser definitivament un èxit.

Grup Creat amb Sketch.

Leave a Comment

Your email address will not be published. Required fields are marked *