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

Hola a todos. Así que soy Misha. Soy ingeniero de UI en Netflix. Así que en Netflix, mi equipo construye herramientas para el análisis de contenido. Para decirlo simplemente, ayudamos a detectar algunas 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 tomó 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 obtuvimos del proceso en tu propia empresa.

Así que para establecer algo de contexto, déjame contarte un poco sobre qué es la plataforma de UI de Netflix. Entonces, ¿qué es eso y por qué lo necesitamos? Imaginemos que te gustaría ver algo en Netflix. Digamos Squid Game. Así que 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étera. Luego se manejan las finanzas, porque necesitas pagar dinero por esas cosas. Finalmente, la película se filma y produce. Se promociona, se localiza, se clasifica por edad. Por cierto, ese es mi equipo, ayudamos a clasificar por edad 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 también 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 plataforma de herramientas. Así que al decir plataforma, me refiero a las herramientas y bibliotecas compartidas, como las comunes, que te ayudan a enviar 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 la 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 elegía las herramientas que mejor les funcionaban. Así que como puedes ver aquí, los empaquetadores de JavaScript que se usaban en las aplicaciones incluyen React Scripts, Vite, Webpack, Gulp. ¿Alguien aquí ha oído hablar de Cracko Cracko? Sí, pero lo estamos usando. Sí, veo a una persona. Genial. Y no se trataba solo de los empaquetadores. La misma historia, la misma distribución de herramientas también era para estilos, para formularios, para tablas, para localización, y para cualquier otra herramienta que puedas imaginar.

Entonces, ¿cómo pasó el equipo de plataforma de ocho empaquetadores diferentes a una recomendación de camino pavimentado? Este proceso tuvo tres fases para ellos. Etapa, fase uno, 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 del monorepo, y qué realmente necesitas enviar como una herramienta común. Luego, la segunda fase es seleccionar. Cuando conoces todas las herramientas que se utilizan, puedes revisarlas, puedes analizarlas, puedes decidir qué es lo mejor para todo el ecosistema de aplicaciones de Netflix. 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 solo clic. Por supuesto, nunca es siempre un solo clic, pero ese es el objetivo.

Así que hoy en día, UiPaved Road, o UiPr, se sostiene sobre dos pilares. Marco web y sistema de diseño Hawkins. Así que el marco es que primero, sí, es muy brillante, el marco es ese primer pilar, y eso es en realidad ese empaquetador de todas las diferentes herramientas que se proporcionan a los equipos. Por eso lo llamamos un marco. Déjame mostrarte cómo se veía la adopción de este marco web para nuestro equipo. Así que esta es una versión muy simplificada de una de nuestras aplicaciones que apoyamos. Así que necesitas un componente de búsqueda de películas, y necesitas este menú de usuario, por ejemplo. Desde el punto de vista arquitectónico, es solo una aplicación monorepo que depende de dos paquetes reutilizables paquetes, búsqueda de películas y menú de usuario. Parece simple, ¿verdad? Pero en realidad no es tan simple, porque es pre-UIPR. Así que es antes de que adoptáramos la plataforma. En cambio, esta aplicación y los paquetes dependen de otro paquete llamado proveedor de aplicaciones. El proveedor de aplicaciones 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 Netflix, y proporcionó algunas herramientas compartidas comunes como configurar el cliente GraphQL, banderas de características, telemetría, y muchas más. El proveedor de aplicaciones reunió todas esas cosas de otros paquetes personalizados que viven dentro de nuestro monorepo.

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, mantenida 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 con configuración, utilidades de prueba como configuraciones de prueba, 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, banderas de características, telemetría, todo eso a la izquierda de la pantalla. Y otras configuraciones también pueden compartir algunos valores predeterminados. Así que 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 liviano ahora.

Pero todavía tenemos ese proveedor de aplicaciones. Y su papel es simplemente reunir esas cosas y proporcionarlas a las aplicaciones y paquetes. Pero si el proveedor de aplicaciones es solo un orquestador de todos esos bucles de plataforma, esto obviamente significa que también debería ser soportado por la plataforma. Cada aplicación no necesita tener su propio proveedor de aplicaciones. Y así es exactamente como nació el marco. Así que ahora nuestras aplicaciones solo necesitan conectarse al punto de entrada del marco, y lo mismo para nuestros paquetes. Y obtenemos todas esas herramientas de 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 marco te da esta configuración de aplicación preconfigurada, lista para la empresa, lista para usar, y todo eso es gestionado por el equipo de plataforma.

El equipo de 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 marco 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 BigBank. Reemplazar el proveedor de aplicaciones, ese orquestador, y todos los paquetes personalizados que teníamos en nuestro monorepo con un marco en todas las aplicaciones y paquetes a la vez. Suena genial. Una pregunta rápida para ti.

¿Quién ha intentado una Migración BigBank así? Y tuvo éxito. Sí. Así que probablemente ahora entiendas hacia dónde va todo esto. Así que 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 al marco web, ¿verdad? Pero luego hay otra aplicación, y también extrae las mismas cosas. Y no puedes tener tanto el proveedor de aplicaciones como el marco web dentro de un solo 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 esas, ¿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 Platform. Como, 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 migrarlos todos. Y tampoco puedes verificar que la migración funcione hasta que completes todo el proceso. Así que eso es como el infierno. Luego 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 nuestro monorepo estaba en un estado un poco heredado, así que algunas bibliotecas estaban desactualizadas, así que necesitábamos actualizarlas, y una vez más necesitas hacerlo para todo el repositorio primero. Algunas características faltantes que el marco no cubría en absoluto, bueno, porque es un producto nuevo en nuestra empresa, así que 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, un millón de líneas de diferencia. Bueno, no era como un millón de líneas, pero aún así muchas. Así que este enfoque falló. Obviamente tuvo algunas victorias. 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 el punto 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 fuimos con 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 una migración de aplicación falla, no bloquea todo el proceso.

Así que con este enfoque hay mucho más verde. Obviamente obtienes flexibilidad porque puedes controlar el tiempo en el que migras cada aplicación. También obtienes soporte personalizado 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 para que cada otra aplicación lo siga. 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 ya que fijamos las dependencias, algunas aplicaciones extraen diferentes versiones de las mismas bibliotecas de terceros. Así que, por ejemplo, la instalación de NPM 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. 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. Como 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 manual a tu compañero de equipo más trabajador. Este. El que nunca se queja de hacer rebase.

Así que los resultados de este enfoque por fases es que pasamos de 2 meses para la migración de la aplicación pionera a menos de 1 semana para cada aplicación subsiguiente. La razón es lo bien documentado que estaba el proceso y lo fácil que era de seguir. Después de eso, después de la migración pionera, 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 principio a fin 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 bloqueo que teníamos y ayudó a dar forma a la migración 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 manual, como guías paso a paso, registros de decisiones, pull requests, algo que cada otro equipo pueda seguir, como cada humano pueda seguir, y no solo humanos, como hicimos nosotros.

Ahora el segundo pilar, el que mencioné. Hawkins design system. Sí, es nuestro sistema interno de Netflix, construido internamente, 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, estabilidad 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 este nuevo adopción del componente de tabla. Así que aquí está una de nuestras tablas en la aplicación. Está implementada usando el componente de tabla de Hawkins, que está construido sobre una biblioteca de terceros React data grid. ¿Has oído hablar de esa biblioteca? Bien. Ahora, ¿has oído hablar de esta? Agigrid React? Sí, lo sé, son patrocinadores de esta conferencia. Por cierto, no están 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, 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 deprecar la antigua para que en el futuro solo usemos este 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? Y tienen tablas. Entonces, ¿usamos la tabla antigua y lanzamos nuevas características ahora? ¿O esperamos al 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 deprecar 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 comenzar a usarlo. Así que equipo de la tabla antigua, levanten las manos. ¿Quién esperaría a que se libere la nueva tabla? Bien, eso es más de ustedes. Así que decidimos que ninguna opción es excelente y encontramos una nueva manera.

Así que aquí está cómo lo abordamos. Paso uno, usar las APIs de HGGrid React directamente. Porque dado que sabemos que se construirá sobre esa biblioteca de terceros, podemos simplemente comenzar a usarla directamente sin esperar a que Hawkins libere este componente. Paso dos, una vez que finalmente se libere, 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 tres, simplemente haz la limpieza y migra gradualmente todas las otras tablas hasta que no tengas referencias a la tabla antigua. Así que 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 deuda técnica 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 componente table next antes de que se libere. La desventaja es que todavía tiene la curva de aprendizaje. También necesitas algunos estilos iniciales y soluciones de licencia, 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, alinea 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 encontrarás en un punto. Segundo, es que el trabajo del producto no es negociable. Tus interesados nunca deberían saber o nunca deberían preocuparse por la migración que estás haciendo.

Y 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 la herramienta perfecta llegue, 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 tú mismo, siéntete libre de escanear el código o encontrarme en LinkedIn en cualquier momento. Gracias. Eres un gran público.

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

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 la construcción de la herramienta? Sí. Así que es importante aquí no aislar tu trabajo. Así que como estamos trabajando en monorepo, en realidad es más fácil porque todos los contribuyentes al monorepo, ven las pull requests que estás creando, ¿verdad? 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, ¿verdad? 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. Creo que tenemos tiempo para un par más. ¿Cuándo crearon y adoptaron el framework de UI de la plataforma? ¿Es algo que es nuevo y ya ha madurado? Si estás hablando del framework web, es bastante nuevo. Diría que tiene un año, pero Hawkins Design System ha existido durante años. Sigue evolucionando y mejorando y algunos nuevos componentes aparecen allí.

Bien. ¿Tienes algún arrepentimiento? Es la segunda parte de esa pregunta. Solo lamento que la IA no apareciera antes en este proceso, pero en general aprendimos mucho de ello. Sí. ¿Puedo pedirte que vengas y te sientes en esta silla para la pregunta final? Lo siento, chicos. Lo siento por la gente en línea. Entonces, otra pregunta es, ¿el framework es obligatorio o todavía tienen equipos que pueden usar sus propias implementaciones? No es obligatorio en este momento porque todavía está en la etapa de desarrollo. Diría que todavía está en la etapa alfa. Pero una vez que no tenga errores, una vez que los equipos estén contentos con él, entonces comenzará a ser obligatorio, creo.

Fantástico. Tenía una pregunta más, pero creo que se ha ido y el tiempo se ha acabado. Así que todos, un enorme agradecimiento nuevamente a Misha por la increíble charla. Muchas gracias. Gracias. Gracias.