Caminando por el Camino Pavimentado de Netflix (Incluidos los Baches): Web Framework, Hawkins Design System

Hola a todos, soy Misha. Soy ingeniera de UI en Netflix. En Netflix, mi equipo construye herramientas para el análisis de contenido. Para decirlo simplemente, ayudamos a detectar cosas aterradoras y para adultos en los títulos. Así que programas como Squid Game o Stranger Things se recomiendan para ti, pero no para tus pequeños. Y también, estos días paso mucho tiempo en la productividad de los desarrolladores, en particular tratando de ayudar a aumentar la adopción de AI, por supuesto, en todos los equipos de Netflix. Pero no voy a hablar mucho sobre AI hoy. Bueno, un poco. En cambio, quiero mostrarte lo que le costó a nuestro equipo de producto adoptar las herramientas de la plataforma de UI, que Netflix proporciona, o como también lo llamamos, las herramientas de camino pavimentado. Habrá dos ejemplos de la vida real, así que dos desafíos de la vida real. Y con suerte, puedes usar los aprendizajes que obtuviste del proceso en tu propia empresa.

Así que para establecer un poco de contexto, déjame contarte un poco sobre qué es la plataforma de UI de Netflix. ¿Qué es eso y por qué la necesitamos? Imaginemos que te gustaría ver algo en Netflix. Digamos Squid Game. Por favor levanta la mano si has visto Squid Game. Genial. Sí, porque tengo muchas referencias a este programa, así que es muy bueno que casi todos ustedes lo hayan visto. Así que vas a Netflix.com, buscas el programa, ahí está. Pero antes de que una película esté lista para reproducirse, en realidad pasa por un largo viaje. Primero necesitas un guion. Luego necesitas firmar acuerdos con actores, escritores, directores, productores, etc. Luego se manejan las finanzas porque necesitas pagar por esas cosas. Y finalmente la película se filma y produce. Se promociona, se localiza, se clasifica por edades. Por cierto, ese es mi equipo. Ayudamos a clasificar por edades las películas. Y eso es solo la superficie. Así que hay cientos de aplicaciones internas que ayudan a impulsar todo este proceso detrás de las escenas. Como cientos de ellas. Y probablemente también hayas oído un poco sobre la cultura de Netflix.

Está construido un poco sobre la velocidad. Necesitas iterar rápido, necesitas pivotar, adaptarte rápido, necesitas ejecutar experimentos, innovar. Y además, los procesos o la burocracia no deberían detenerte. Así que hay un mínimo de esos. Pero también para que el negocio tenga éxito, necesita equilibrar esas cosas con calidad, consistencia, previsibilidad y soporte multiplataforma. Para que cada dispositivo lo soporte, para que no encuentres errores. Sé que hay algunos, pero con suerte hay una cantidad mínima de esos. Y estos dos grupos, no siempre coinciden. Así que Netflix ha ideado una solución para este desajuste, y esta solución es la herramienta de plataforma.

Así que al decir plataforma, me refiero a las herramientas y bibliotecas compartidas, como las comunes, que te ayudan a lanzar aplicaciones rápidamente sin sacrificar la calidad. Y en el lado de la interfaz web, llamamos a esas herramientas UI-paved road. Como un camino por el que puedes conducir o caminar, así que es más fácil para ti. Pero el spoiler es que hay algunos baches en este camino, y te guiaré a través de algunos de ellos. Entonces, ¿por qué migrarías a la plataforma en absoluto? Porque cada base de código crece en complejidad con el tiempo, ¿verdad? Pero cuando migras a las herramientas de plataforma, una gran parte de esa complejidad desaparece.

Porque ya no necesitas soportar todas esas soluciones personalizadas que de otro modo tendrías que soportar, si no se proporcionaran. Así que después de adoptar la plataforma, la complejidad, el esfuerzo de mantenimiento y la incorporación disminuyen, y al mismo tiempo, esas cosas que mencioné antes, como la fiabilidad, también la productividad, consistencia y seguridad, todas aumentan. Porque el equipo de la plataforma ahora se encarga de todo por ti. Y solo para reiterar, al decir plataforma, no me refiero a cosas como Android, iOS o web, solo me refiero a esta combinación de herramientas, específicamente en el lado de la interfaz web, que se envían para que los equipos de producto sean más rápidos y más productivos. Así que esto es lo que teníamos antes de las herramientas de plataforma, o antes de UI-PR, como lo llamamos.

Así que cada equipo eligió las herramientas que mejor les funcionaban. Como pueden ver aquí, los empaquetadores de JavaScript que se usaron en las aplicaciones incluyen React Scripts, Vid, Webpack, Gulp. ¿Alguien aquí ha oído hablar de CrackoCracko? Sí, pero lo estábamos usando. Veo a una persona. Genial.

Y no se trataba solo de los empaquetadores. La misma historia, la misma distribución de herramientas también fue para estilos, para formularios, para tablas, para localización y para cualquier otra herramienta que se te ocurra. Entonces, ¿cómo pasó el equipo de la plataforma de ocho empaquetadores diferentes a una recomendación de camino pavimentado? Este proceso tuvo tres fases para ellos.

Fase 1, analizar. Mira las cientos de aplicaciones, qué están usando, qué están compartiendo, dónde no están de acuerdo, qué es específico de la aplicación, qué es específico de Monorepo, y qué realmente necesitas enviar como una herramienta común. Luego, la segunda fase es seleccionar.

Y comenzar a apoyarlo como una plataforma. Y la tercera etapa es que necesitas agrupar esas herramientas para que los equipos puedan simplemente adoptarlas con un solo clic, como una instalación de un clic. Por supuesto, nunca es siempre un clic, pero ese es el objetivo.

Así que hoy en día, UiPaved Road, o UiPR, se sostiene sobre dos pilares, el marco web y el sistema de diseño Hawkins. Así que el marco es eso primero. Sí, muy brillante.

El marco es ese primer pilar, y en realidad es ese agrupador de todas las diferentes herramientas que se proporcionan a los equipos. Por eso lo llamamos un marco. Déjame mostrarte cómo fue la adopción de este marco web para nuestro equipo. Así que esta es una versión muy simplificada de nuestra aplicación, de una de nuestras aplicaciones que apoyamos.

Así que necesitas un componente de movie search, y necesitas este user menu, por ejemplo. Desde el punto de vista arquitectónico, es solo una aplicación monorepo que depende de dos paquetes reutilizables, movie search y user menu. Parece simple, ¿verdad? Pero en realidad no es tan simple porque es antes de UiPR. Así que es antes de que adoptáramos la plataforma. En cambio, esta aplicación y los paquetes dependen de otro paquete llamado application provider.

Es como un proveedor de todas esas herramientas personalizadas. También otro paquete personalizado que teníamos en nuestro monorepo. Manejó la integración con sistemas internos, como la autenticación en el sistema de red, y proporcionó algunas herramientas comunes compartidas como configure-graphql-client, feature-flex, telemetry, y muchas más. Application provider reunió todas esas cosas de otros paquetes personalizados que viven dentro de nuestro monorepo. Un monorepo de 50 paquetes y 10 aplicaciones. Todo lo que poseemos, como nuestro equipo posee.

Además de eso, también hay esta capa comunitaria de algunas bibliotecas para autorización, inicio de sesión, y más, mantenidas por toda la comunidad empresarial de Netflix. Y cada aplicación también tiene sus propias configuraciones y lógica de generación de código, como typescript config, vidconfig, testutils y cosas así. Así que esta es la configuración heredada que heredamos. Y si miras más de cerca este esquema, puedes ver que muchas de esas cosas pueden realmente ser reutilizadas en múltiples aplicaciones. Porque la mayoría de las aplicaciones necesitan cosas como autorización, manejo de errores, feature-flex, telemetry, todo eso a la izquierda de la pantalla. Typescript y otras configuraciones también pueden compartir algunos valores predeterminados.

Esto debe ser proporcionado por la plataforma, por el equipo de UIPR. Y de hecho lo es. Así que nuestro equipo de plataforma trabajó duro y ahora tenemos la equivalencia de todas esas cosas proporcionadas por ellos. Así que ya no necesitamos mantener todas esas alternativas personalizadas en nuestro monorepo. Y puedes ver que el monorepo es mucho más ligero ahora. Pero todavía tenemos ese proveedor de aplicaciones, y su papel es solo reunir esas cosas y proporcionarlas a aplicaciones y paquetes.

Pero si el proveedor de aplicaciones es solo un orquestador de todas esas bibliotecas de la plataforma, esto obviamente significa que también debería ser soportado por una plataforma. Cada aplicación no necesita tener su propio proveedor de aplicaciones. Y así es exactamente como nació el framework. Así que ahora nuestras aplicaciones solo necesitan conectarse a un punto de entrada del framework, y lo mismo para nuestros paquetes. Y obtenemos todas esas herramientas de la plataforma listas para usar. Así que no más paquetes de infraestructura personalizados viviendo en nuestro monorepo. Ese es el estado ideal de nuestro monorepo.

La aplicación solo necesita manejar la lógica de negocio y nada más. Así que para reiterar una vez más, el framework te ofrece esta configuración de aplicación preconfigurada y lista para la empresa lista para usar, y todo eso es gestionado por el equipo de la plataforma. El equipo de la plataforma también mantiene tus dependencias actualizadas, y también proporciona un sistema de plugins en caso de que aún necesites algo personalizado. Así que ahora, con suerte, puedes ver por qué el framework se convirtió en el objetivo de migración para nuestras aplicaciones internas. Pero también fuimos uno de los primeros equipos en migrar, así que tuvimos que averiguar el proceso primero, para no ser como ese tipo.

Así que nuestro primer enfoque, migración de gran golpe. Reemplazar el proveedor de aplicaciones, ese orquestador, y todos los paquetes personalizados que teníamos en nuestro monorepo con un framework para todas las aplicaciones y paquetes a la vez. Suena genial. Una pregunta rápida para ti. ¿Quién ha intentado una migración de gran golpe así y ha tenido éxito? Sí. Probablemente ahora entiendas hacia dónde va todo esto. Una vez más, el esquema de nuestro monorepo.

La aplicación y los paquetes dependen todos del proveedor de aplicaciones. Entonces solo necesitas cambiar esas dependencias a un framework, ¿verdad? Pero luego hay otra aplicación, y también extrae las mismas cosas. No puedes tener tanto el proveedor de aplicaciones como el framework web dentro de un monorepo porque bajo el capó configuran las mismas herramientas. Así que tenemos conflictos de dependencias. No es tan fácil resolverlos. Así que necesitarías migrar esa segunda aplicación también.

Pero luego tenemos más de esos, ¿verdad? Tenemos 50 paquetes y 10 aplicaciones. Así que no puedes migrar una de esas cosas sin migrar todas. Es como un efecto bola de nieve. Y ese es el gráfico de dependencias real de nuestro monorepo antes de adoptar la plataforma. Esta cosa en el centro es el proveedor de aplicaciones, y muchos de esos bloques son esos paquetes personalizados. Así que durante este enfoque, los problemas siguieron acumulándose. Así que el primer problema es este acoplamiento estrecho. Porque todas las aplicaciones y paquetes dependen de las mismas cosas y no puedes migrar uno sin migrar todos.

Y tampoco puedes verificar que la migración funcione hasta que completes todo el proceso. Así que eso es como un infierno. Y los errores están por todas partes. Es imposible detectar de manera confiable todas las regresiones hasta que completes todo el proceso y nunca sucede. Características incompatibles, porque, bueno, nuestro monorepo estaba en un estado algo heredado. Así que algunas bibliotecas estaban desactualizadas, por lo que necesitábamos actualizarlas, y una vez más necesitas hacerlo para todo el repositorio primero.

Algunas características faltantes que el framework no cubría en absoluto, porque es un nuevo producto en nuestra empresa. Así que sí, tuvimos que proponer comentarios sobre lo que necesita ser agregado. La coordinación entre equipos es, como dije, porque todos los equipos necesitan entregar la migración y hasta que lo hagan, el proceso no puede completarse. Y obviamente cada equipo también tiene su propia hoja de ruta. Rebases frecuentes para mantenerse al día con el desarrollo.

Y la guinda del pastel, una diferencia de un millón de líneas. No era como un millón de líneas, pero aún así mucho. Así que este enfoque falló. Obviamente tuvo algunas, ya sabes, ventajas. No las victorias, sino los pros. Por ejemplo, solo necesitas hacerlo una vez para todo el monorepo y está hecho. Todos se benefician de lo que proporciona la plataforma. También es un esfuerzo enfocado que puedes rastrear y poner en tu hoja de ruta, en tu sprint, o como sea que gestiones proyectos. También expuso todos los problemas que tenemos. Pero la conclusión aquí es que no hay margen de error con este enfoque. Un bloqueo detiene todo el proceso y los equipos también tienen que esperar unos a otros.

Y las regresiones también son muy difíciles de detectar y verificar. Y después de cada cambio, también necesitas pasar por todo ese proceso de verificación desde el principio para todas las aplicaciones. Así que no es sostenible. Así que en su lugar optamos por este enfoque por fases, el segundo enfoque. Dividimos este esfuerzo de migración en tres fases. Fase de preparación, la migración en sí, y los seguimientos. Y también fijamos las dependencias por aplicación, para que el framework y el proveedor de aplicaciones y todas esas cosas personalizadas puedan coexistir juntas. Esto resolvió este infierno de conflictos de dependencias y nos desbloqueó para migrar aplicaciones una por una, como aplicación por aplicación.

Así que comenzamos con una aplicación pionera para entender el proceso y estimar el esfuerzo. Luego lo replicamos en la segunda aplicación, luego en la siguiente. E incluso si falla la migración de una aplicación, no bloquea todo el proceso. Así que con este enfoque, hay mucho más verde. Obviamente obtienes flexibilidad porque puedes controlar el tiempo de cuándo migrar cada aplicación. También obtienes soporte de guante blanco de la plataforma porque es más fácil para ellos ayudarte con la migración de una aplicación en lugar de todo tu Monorepo. Y también la aplicación pionera se convierte en el modelo a seguir para cada otra aplicación.

En cuanto a las compensaciones, algunas aplicaciones aún se quedan atrás porque algunos equipos comienzan la migración más tarde. Y el Monorepo también está un poco desordenado temporalmente porque, dado que fijamos las dependencias, algunas aplicaciones tiraron de las mismas, perdón, tiraron de diferentes versiones de las mismas bibliotecas de terceros. Así que, por ejemplo, npm install tomó como 20 minutos hasta que completamos todo este proceso. Pero aún así, comparado con el enfoque anterior, eso es mucho mejor. Y aquí está este enfoque en práctica. Sí, probablemente no veas todo lo que está escrito allí, pero ese es exactamente el punto. Porque ahora, en lugar de un esfuerzo masivo para la migración, tienes esta lista de pequeñas tareas independientes.

El mismo conjunto de pasos que cada equipo puede seguir. Y cada fase también se puede hacer por separado. Y esos elementos se pueden paralelizar y verificar por su cuenta. Y una vez que has documentado este proceso, como este plan de alto nivel, las guías paso a paso, las pull requests, puedes entregar ese runbook a tu compañero de equipo más trabajador. Este. El que nunca se queja de reembolsar.

Así que los resultados de este enfoque por fases es que pasamos de dos meses para la migración de la aplicación Pioneer a menos de una semana para cada aplicación subsiguiente. La razón es lo bien que se documentó el proceso y lo fácil que fue seguirlo. Después de eso, después de la migración de Pioneer, convertimos la documentación y los artefactos como pull requests y cosas en una habilidad de agente para que la IA pueda ejecutar la migración de extremo a extremo por ti. Y la documentación y la habilidad también resultaron útiles no solo para nuestro monorepo sino en toda la empresa.

Así que lo que aprendimos de eso es primero, divide y vencerás, ¿verdad? Porque Big Bang falló porque era tan grande y monstruoso, así que es mejor enviar un pequeño elemento a la vez. Falla rápido, pero adáptate más rápido. Big Bang falló, pero también expuso cada bloqueador que teníamos y ayudó a dar forma a la migración del enfoque por fases. Colabora con la plataforma. Dimos retroalimentación temprana sobre esas características faltantes. Se corrigieron algunos errores y el framework se volvió mucho mejor de lo que era al principio. Y finalmente, deja un runbook como guías paso a paso, registros de decisiones, pull requests, algo que cada otro equipo pueda seguir, como cada humano puede seguir y no solo humanos como lo hicimos.

Ahora, el segundo pilar, el que mencioné, Hawkins Design System. Es nuestro sistema interno de Netflix, como construido sobre Material UI. Básicamente, esos son los bloques de construcción de tu aplicación. Así que estos son componentes, formularios, tablas, guías, métricas de uso, todo construido con rendimiento, fiabilidad y consistencia en mente por nuestro equipo de plataforma.

Así que uno de los estudios de caso o desafíos que enfrentamos con este sistema de diseño es esta nueva adopción del componente de tabla. Así que aquí está una de nuestras tablas en la aplicación. Está implementada usando Hawkins Table Component, que está construido sobre una biblioteca de terceros, React Data Grid. ¿Has oído hablar de esa biblioteca? OK, ahora, ¿has oído hablar de esta? Agigrid React. Sí, lo sé. Son patrocinadores de esta conferencia. Por cierto, no estamos afiliados.

Así que nuestro equipo de Hawkins decidió usar Agigrid para construir la próxima versión del componente de tabla porque tiene más características y también es más rápido, como que el rendimiento es mejor. Así que en general es mejor. Así que están llamando a ese componente Hawkins Table Next. Y dado que las APIs son diferentes para esas bibliotecas de terceros, quieren duplicar la antigua, para que en el futuro solo usemos Hawkins Table Next. Pero eso es solo un anuncio porque este componente aún está en desarrollo. Entonces, ¿cómo procedemos ahora? Porque como equipo de producto, necesitamos seguir lanzando nuevas características, ¿verdad?

Entonces, ¿esperamos, perdón, usamos la tabla antigua y lanzamos nuevas características ahora? ¿O esperamos el nuevo componente y lanzamos características más tarde? Así que para la tabla antigua, tenemos estos pros y contras. No hay retraso en el trabajo del producto. Las APIs son familiares. Y el principal contra aquí es que estás creando deuda técnica por adelantado, porque en el futuro necesitarías duplicar ese componente.

Para la nueva tabla, no estás creando la deuda técnica, pero hay un retraso en el trabajo del producto y también hay una curva de aprendizaje porque necesitas aprender las nuevas APIs antes de empezar a usarlo. Así que equipo de la tabla antigua, levanten las manos. ¿Y quién esperaría a que se libere la nueva tabla? Decidimos que ninguna opción es excelente y encontramos una nueva manera.

Así que aquí está cómo lo abordamos. Paso 1. Usar directamente las APIs de Agigrid React. Porque como sabemos que se construirá sobre esa biblioteca de terceros, podemos simplemente empezar a usarla directamente sin esperar a que Hawkins libere este componente.

Paso 2. Una vez que finalmente se libera, solo necesitas intercambiar un componente por otro. Y dado que las APIs son similares, será más fácil que migrar a este componente desde cero. Y finalmente, paso 3. Simplemente haz la limpieza y migra gradualmente todas las otras tablas hasta que no tengas referencias a la tabla antigua. Así que sí, llamamos a este enfoque adopción anticipada, porque no he encontrado ningún otro patrón arquitectónico similar. Y las ventajas aquí son que no hay retraso en el trabajo del producto, tienes menos datos técnicos que abordar más tarde, y también puedes dar retroalimentación temprana sobre las características. Así que puedes dar forma al lanzamiento del próximo componente de la tabla antes de que se libere.

La desventaja es que todavía tiene la curva de aprendizaje. También necesitas algunos ajustes iniciales de estilo y licencias, ya que estás usando la biblioteca de terceros directamente. Y hay una pequeña limpieza después del intercambio final. Pero comparado con las alternativas, encontramos que es un mejor enfoque. Así que lo que aprendimos de esto es primero, alinear la dirección y no el tiempo. Porque no siempre puedes esperar a la plataforma, porque algunos trabajos de producto no pueden esperar. Así que en su lugar, si alineas la dirección hacia donde te estás moviendo, te encuentras en un punto. Segundo, es que el trabajo del producto no es negociable. Tus interesados nunca deberían saber o nunca preocuparse por la migración que estás haciendo. Esto es lo que te mantiene confiable y responsable para tomar tales decisiones en el futuro. Y finalmente, da retroalimentación temprana. Como dije, nuestra retroalimentación ayudó a dar forma al lanzamiento final. Así que la próxima vez que estés esperando que caiga la herramienta perfecta, comienza con lo que ya tienes. Alinea temprano y abre el camino tú mismo.

Y por cierto, estamos contratando en Netflix. Así que si algo de lo que viste te resultó familiar o te trajo recuerdos, o si quieres trabajar en desafíos similares, siéntete libre de escanear el código o encontrarme en LinkedIn en cualquier momento. Gracias. Eres un público genial.

Comenzaré con una pregunta de un anónimo. ¿Cómo le transmitiste al liderazgo que valía la pena seguir este proyecto? Puede ser un desafío justificar la re-arquitectura y la migración. Sí, estoy de acuerdo en que la aceptación es probablemente la parte más desafiante. Pero diría que no fue solo nuestro movimiento para convencer al liderazgo, sino que también fue la decisión que el equipo de plataforma tuvo que seguir. Porque inicialmente, es su equipo el que es responsable de introducir todas esas herramientas comunes compartidas. Y básicamente es su papel convencer al liderazgo.

Fantástico. Gracias. Y otra pregunta es, ¿cómo evitaste que los equipos de producto se aislaran en su propia pequeña isla? Me encanta que mencionaras al final sobre asegurarte de que nunca sepan sobre los detalles de implementación de paquetes y migraciones. Pero, ¿cómo intentas que contribuyan a la migración o a la construcción de la herramienta? Sí, así que aquí es importante no aislar tu trabajo. Así que, dado que estás trabajando en Monorepo, en realidad es más fácil. Porque todos los contribuyentes al Monorepo ven las pull requests que estás creando. Y también es más fácil para ellos comenzar a hacer estas cosas por su cuenta después de que tienen un ejemplo. Y especialmente después de que creamos la habilidad de migración, se volvió aún más fácil.

Porque ahora solo necesitan ejecutar la habilidad y verificar que funciona después de que la habilidad está hecha. Genial. Gracias. Y tenemos tiempo para un par más.

¿Cuándo crearon y adoptaron el framework de UI de la plataforma? ¿Es algo reciente? ¿Y ya ha madurado? Si estás hablando del framework web, es bastante reciente. Diría que tiene un año. Pero Hawkins Design System existía desde hace años. Solo seguía evolucionando y mejorando. Y algunos nuevos componentes aparecen allí. OK.

¿Y tienen algún arrepentimiento?, es la segunda parte de esa pregunta. Solo lamento que AI no apareciera antes en este proceso. Pero en general, aprendimos mucho de ello. Sí. ¿Puedo pedirte que vengas y te sientes en esta silla? Sí. Claro. Lo siento, chicos.