La Era de los Monorepos

Y con esa nota formal, permítanme presentarme. Mi nombre es Miroslav Janas. Trabajo para Narval en la herramienta llamada nX, de la que escucharán mucho hoy. También coorganizo dos encuentros en Viena, ViennaJS y AngularVienna.

Ahora, antes de sumergirnos en lo que son los monorepos, para entender cómo llegamos al punto en el que se necesitan los monorepos, debemos hacer un viaje al pasado, hasta los inicios de la web, para rastrear nuestros pasos y ver cómo llegamos aquí. Abróchense los cinturones, es hora de la historia.

Al principio, como todos saben, la web era estática. Era simplemente una colección de páginas HTML enlazadas con hipervínculos. Las primeras páginas web se veían algo así como esta página de Yahoo. Tenían mucho texto, muchos enlaces, imágenes muy pequeñas, era la época de la conexión dial-up, por lo que las cosas tenían que ser pequeñas y rápidas. Por lo general, tenían una elección de colores contrastantes, pero las páginas eran aburridas. Eran demasiado estáticas, así que la gente ideó un formato gráfico que daría un poco de vida. ¿Quién recuerda a este bebé bailarín? Algunas páginas llevaron esto a un nivel completamente nuevo, donde toda la página estaba girando en animations. Pero verán, aún no era lo que necesitábamos porque esto se ejecutaba en un bucle, no era una animación controlada, no era un movimiento controlado. Entonces, a Brendan Eich de Netscape, una empresa que producía el navegador popular en ese momento, se le asignó la tarea de crear un lenguaje en solo dos semanas que recogiera algunas ideas de Java y que finalmente llevara dinamicidad al navegador. Y dos semanas después, nació LiveScript, que luego se renombró a JavaScript, para deleite de generaciones de reclutadores y cazatalentos desde entonces.

Y así comenzó la era de la programación de scripts y con esto finalmente tuvimos páginas con galerías de imágenes elegantes, teníamos efectos de menú locos, botones que huían de nuestro cursor, pero las páginas, bueno, todavía podían verse muy feas, pero al menos tenían movimiento controlado finalmente. Y a medida que el número de scripts en una página crecía, comenzamos a encontrar ciertos patterns para reconocer ciertas cosas que se repetían. Al mismo tiempo, este fue un momento de famosas guerras de navegadores entre Microsoft y Netscape y había muchas inconsistencias entre los estándares en estos dos navegadores, por lo que los desarrolladores generalmente tenían que implementar cosas para ambos navegadores. Afortunadamente, ahora teníamos bibliotecas de ayuda, especialmente jQuery, que superaría estas diferencias y crearía una envoltura alrededor de la manipulación del DOM. Esto te permitiría crear rápidamente tus sitios web. Y a medida que los sitios web se volvieron más y más complicados, comenzamos a llamarlos aplicaciones web, no sitios web.

Pero encapsular el DOM y las animations no era la única plantilla. Todavía había mucho por encapsular, como el enrutamiento, la gestión de eventos, la gestión del estado, y esto fue lo que llevó a las aplicaciones de una sola página. El primer framework popular que implementó aplicaciones de una sola página fue AngularJS, y pronto le siguieron React y Vue. Todos ellos todavía se usan hoy en día en algunas variaciones y juntos cambian nuestra forma de pensar en el desarrollo web. Establecieron el desarrollo web tal como lo conocemos hoy. Desafortunadamente para ellos, este también fue el momento en que nuestros teléfonos se volvieron inteligentes y ahora de repente ya no navegamos por Internet en nuestras computadoras de escritorio, sino que comenzamos a navegar por Internet en nuestros teléfonos móviles mientras estábamos sentados en bancos de parques o en transporte público o sentados en un asiento de inodoro. En estos lugares, la conexión no era realmente estable. Podíamos esperar como máximo 3G con muchas interrupciones.

Y de repente nos dimos cuenta de que las aplicaciones de una sola página eran demasiado pesadas para los teléfonos móviles y necesitábamos abordar esto. Y la gente estaba acostumbrada a tener sitios web rápidos, así que de repente, cuando tenías que esperar minutos para que algo se cargara, simplemente no funcionaba. Y esto llevó al surgimiento de Jamstack, donde necesitábamos algo que fuera rápido y ligero en contraste con las grandes aplicaciones de una sola página que tardaban minutos o incluso decenas de minutos y megabytes en cargarse.

Necesitábamos abordar el elefante que intenta ser exprimido por una pajita. Fue el nacimiento de los primeros meta frameworks como Next, Nuxt o Gatsby o los populares hoy en día Remix, Quik y Astro que aportan algo nuevo, donde finalmente teníamos páginas que se cargaban rápidamente, donde verías los resultados de inmediato. Desafortunadamente, todo esto se hizo a expensas de la experiencia del desarrollador. Para tener sitios web rápidos para los usuarios, teníamos que hacer un trabajo pesado en nuestras propias máquinas, por lo que nuestros procesos de compilación se volvieron extremadamente lentos. Y no solo esto frustraba a los desarrolladores, sino que cuando consideramos que la mayoría de las CI y CD ahora se realiza en la nube, si nuestros procesos de compilación eran lentos, eso también significaba que nuestros compilaciones mensuales en la nube eran cada vez más altas.

Era hora de abordar la segunda parte de la lentitud, por lo que ahora los sitios web eran lentos pero necesitábamos trabajar rápido, pero necesitábamos acelerar nuestra experiencia del desarrollador. Esto llevó a los monorepos. Para entender qué hacen exactamente los monorepos, consideremos primero nuestra aplicación web típica de hoy en día. Nuestra aplicación generalmente consta de una aplicación de front-end construida con el framework elegido, y luego tenemos algún back-end que no es un back-end monolítico, sino que tiene una arquitectura de microservicios detrás, y luego tienes algunos componentes de interfaz de usuario. Ahora, lo que sucede ocasionalmente es que uno de los desarrolladores que trabaja en el back-end cambia ligeramente un método en uno de los servicios, cambiando así un contrato, y simplemente olvida informar al mantenedor del front-end, y de repente tu sitio web está roto, todos te están señalando con el dedo y no tienes idea de qué sucedió porque no tocaste ese código.

Hay algunos intentos torpes de resolver esto exportando constantemente contratos desde el back-end, convirtiéndolos a TypeScript e importándolos en tus aplicaciones de front-end para tener siempre información actualizada, pero esto requiere intervención manual y cuando se trata del factor humano, dado suficiente tiempo, eventualmente fallará. Y además de eso, hay un problema de sincronización porque si algo cambia en el back-end, tienes que implementarlo al mismo tiempo en el front-end, y hay mucha coordinación y malabarismo involucrado. Además de eso, tu aplicación puede no ser la única. Puede haber dos aplicaciones adicionales, una dedicada a móviles y un portal de administración dedicado tal vez construido con una tecnología completamente diferente que también se comparte entre diferentes aplicaciones.

Ahora, lo que quieres hacer es que cada vez que uno de estos cambie, cada parte del sistema que se haya visto afectada por él sea notificada de inmediato. Ahora, en un enfoque de poli-repo típico, lo que sucede es que, por ejemplo, si cambias la utilidad, tendrías que publicar una nueva versión, luego actualizar las dependencias en la aplicación de la página de inicio y el portal de administración, y luego probar si esto funciona. Si no funciona, tienes que volver atrás, hacer una corrección en la utilidad y publicar una nueva versión. Por supuesto, esto se puede resolver con, por ejemplo, enlaces SIEM o algún repositorio local, pero requiere mucha coordinación, muchas cosas que debes mantener y además de eso, esto no escala bien.

Ahora, ¿no sería bueno si simplemente pudieran hablar entre sí? Entonces, cada vez que algo cambie, todo el ecosistema ya sabe qué sucedió. Y esto es lo que sucede con la colocación. La colocación significa que todos estos proyectos están en el mismo repositorio. Entonces, cada vez que uno de estos cambia, todos los proyectos pueden verlo de inmediato porque están juntos, por lo que no es necesario publicar una nueva versión, no es necesario ningún despliegue o cualquier otro ritual. Ahora, tener las cosas colocadas también nos ayuda a identificar ciertas funciones que se pueden, por ejemplo, reutilizar. Entonces, si tienes alguna función sofisticada de administración como esta en tu código, puedes decirle fácilmente a tus colegas: `Oye, tengo esta increíble función, tal vez quieras usarla en tu proyecto también`. Y ellos pueden verlo y decir: `Sí, increíble, también necesitamos esto para el teléfono móvil`. Y puedes extraer esto fácilmente en una biblioteca y compartirla con todos los demás en el repositorio. Y cuando la gente piensa en los monorepos, esto es lo que generalmente piensan, que se trata solo de la colocación. Pero no se trata solo de la colocación.

La colocación es solo una condición previa para todo lo demás. Es la velocidad lo que más destaca en los monorepos. Entonces, ¿cómo logramos esta velocidad? En primer lugar, cuando tenemos todo en un mismo lugar colocado, podemos identificar fácilmente cómo están conectadas las cosas. Y al saber cómo están conectadas las cosas, podemos crear este bonito gráfico de dependencias. Por ejemplo, si cambiáramos aquí nuestra biblioteca principal, podemos ver que los únicos dos proyectos que podrían verse afectados son store y admin.

Además, si el comando que estamos intentando ejecutar es deploy, sabemos que esta biblioteca principal es solo un bloque de construcción, no se despliega. Así que no hay nada que hacer allí. Pero nuestros store y admin sí se despliegan. Por lo tanto, al saber qué objetivo estamos ejecutando y cómo están conectadas las cosas, podemos reducir este gráfico completo a solo dos nodos. Ahora imagina si este gráfico completo tuviera cientos de proyectos. ¿Cuánto ahorrarías allí? En lugar de ejecutar build, por ejemplo, para todos estos proyectos, simplemente ejecutarías build para core, store y admin, y luego desplegarías solo store y admin.

Nuevamente, si sabemos cómo están conectadas las cosas, siempre podemos tener un gráfico de dependencias actualizado. Podemos tener un gráfico de arquitectura actualizado. Así que ya no tienes que mantener diagramas arquitectónicos obsoletos en tus unidades de red. Simplemente puedes ejecutar el comando y obtener un diagrama actualizado de inmediato. Y no solo eso, puedes filtrarlo fácilmente por nodos, puedes hacer clic en los vértices y ver qué archivos crean esta conexión entre dos proyectos. Puedes ver si tienes algunas dependencias circulares. Puedes detectar todos estos problemas. Si sabemos cómo están conectadas las cosas, podemos crear una buena orquestación de tareas, porque podemos saber en qué orden deben procesarse las cosas. Entonces, si necesitamos, por ejemplo, ejecutar test, build y lint, una forma ingenua sería simplemente ejecutarlos secuencialmente, primero build, luego lint y luego test. Supongamos que test incluye pruebas de extremo a extremo, por lo que debemos hacerlo después de la compilación. Una mejor forma sería, por supuesto, ejecutar build y lint en paralelo porque no dependen entre sí, y luego ejecutar test después. Una forma aún mejor sería comenzar a ejecutar las pruebas tan pronto como las partes que deben ser probadas estén construidas. Y si alguna vez usaste Learnr hasta hace un mes, este era el límite de sus capacidades. Y estaba bien para la mayoría de las cosas, pero también dejaba mucho que desear. Y en este estado de limbo, surgieron muchas nuevas herramientas de Monorepo y ofrecieron más funcionalidades sobre Lerna. Esto cambió recientemente cuando Narwal se hizo cargo de Lerna, porque ahora con una sola bandera use NX, puedes tener la mayoría de las funcionalidades que NX, una de las herramientas populares de Monorepo, proporciona. Entonces, Lerna ahora también es competitivo con todas las demás herramientas y se volvió mucho más rápido que antes. Y también hay un nuevo sitio web, así que si no lo has revisado, puedes ir y revisar el sitio web. No ahora, después de la charla.

Como mencioné, ahora está impulsado por NX. Esto es opcional, por lo que puedes activarlo o desactivarlo si no te gusta, depende de ti. Entonces, ¿cuáles son estas otras herramientas de Monorepo? Empresas como Google y Facebook han tenido sus soluciones de Monorepo durante mucho tiempo. Los repositorios consisten en miles de proyectos que se ejecutan constantemente y para este tipo de ecosistema, necesitas herramientas de construcción realmente sofisticadas para ejecutar esto en tiempo real, ¿verdad? Y tomó mucho tiempo que esto sucediera. Pero hasta hace poco, no estaba abierto al público. Pero una vez que se abrió al público, aunque nos dimos cuenta de lo impresionantes que son estas herramientas, había un pequeño inconveniente. Podrías necesitar un doctorado para poder configurarlo, porque casi nada estaba automatizado. Requería muchas configuraciones, y no solo una vez. Una y otra vez, cada vez que creas un nuevo proyecto. Entonces, para mantener esto en tu repositorio, podrías necesitar a una persona dedicada que haga solo esto. Esto no era, por supuesto, factible para ninguna empresa más pequeña. Pero afortunadamente, empresas como Microsoft, con Rush y Lagge, o Narwa con NX, o Verso ahora con TurboRepo, ofrecieron soluciones que brindan más o menos el mismo conjunto de funciones, pero automatizadas, sin todas las plantillas que debes hacer manualmente.

Entonces, ¿cuáles son estas características que nos faltan en Learnr? La más importante es la caché. La caché es una premisa de que no deberías tener que ejecutar código que ya has ejecutado. Entonces, si estás ejecutando, por ejemplo, una construcción en tu estado del repositorio, si necesitas ejecutarlo nuevamente, deberías tener solo los resultados reproducidos. ¿Por qué luchar de nuevo? Y esto es lo que hace la caché.

Por ejemplo, si ejecuto una construcción en mi sistema, se almacenará en una caché. Y no solo mis artefactos, sino también mis bloqueos. Entonces, la próxima vez que lo ejecute, no solo copiará esos artefactos como si estuviera ejecutándolo ahora, sino que también reproducirá todos los bloqueos, por lo que ni siquiera notarías que se estaba ejecutando desde una caché aparte de estar allí de inmediato.

Pero, ¿qué sucede si tienes un colega, por ejemplo, en Australia, y están ejecutando el mismo comando en el mismo estado del repositorio? Tendrían que hacerlo nuevamente, porque no pueden ver tu caché local. Pero afortunadamente, con una caché remota, no solo puedes almacenar tu caché localmente, sino que también puedes almacenarla en la cloud. Entonces, la próxima vez que tu colega intente cargar o ejecutar la construcción, primero verificará si está disponible en mi caché local. Si es así, lo copiaremos desde la caché local, si no, verificaremos la cloud. ¿Está allí? Si es así, lo copiaremos desde la cloud, de lo contrario, lo ejecutaremos desde cero, lo guardaremos en la caché local y lo guardaremos en la cloud. Y esto no solo ahorra tiempo al desarrollador, sino que también ahorra una cantidad tremenda de tiempo en CI, especialmente porque mientras trabajas en tu PR en tu función, ya estás construyendo estas cosas en tu máquina, y tu cloud ya lo sabe. Entonces, cuando ejecutas el CI, el CI solo recoge cosas de la caché. Y esto no solo ahorra tiempo mientras esperas el PR, sino que también ahorra una gran cantidad de dinero en tus facturas mensuales de la cloud.

La siguiente característica muy interesante es la ejecución de tareas distribuidas. No importa cuán buena sea la implementación de tu caché, o cuán eficiente sea tu grafo afectado, hay ocasiones en las que todo esto no importa. Por ejemplo, si estás actualizando la versión de tu framework, de repente todo se ve afectado y tu caché deja de existir, porque tienes una versión completamente nueva del framework. Así que toda la caché que tienes deja de funcionar. Puede estar rota. Así que tienes que ejecutar todo desde cero. Y aunque esto pueda no parecer importante, hemos visto soluciones con cientos de proyectos donde simplemente ejecutar la construcción lleva una hora y media. Sus construcciones nocturnas duran un día y medio. Así que ni siquiera es nocturno, ya es por la noche. E imagina si tuvieran que ejecutar esto cada vez que algo importante cambie en su framework. O si tienen alguna refactorización importante, sería un desastre. Afortunadamente, la ejecución de tareas distribuidas nos da la capacidad de ejecutar cosas en paralelo o en múltiples agentes. Es decir, por ejemplo, si tenemos cien tareas que necesitamos completar, podemos dividirlas en, digamos, cinco agentes y cada uno toma 20 tareas. Pero no es tan simple porque las tareas no tienen el mismo tamaño. Pueden estar entrelazadas, puede haber dependencias. Y además de eso, si algo falla, no quiero revisar todos los agentes para ver exactamente dónde falló. Quiero ver un informe unificado. Y es por eso que la ejecución de tareas distribuidas es el problema más difícil de los monorepos. Y hasta ahora, solo dos soluciones de monorepos, Bazel y NX, lo están implementando.

La siguiente característica muy interesante son las restricciones de código. Esta es tu única arma contra arquitecturas inmanejables. Estás trabajando en algunas características experimentales y, hasta que termines completamente y aún estés experimentando, de repente alguien comienza a usar tu característica en su proyecto. Y ahora no solo tienes una dependencia, que cada vez que cambias algo, podría romper el cambio para ellos, sino que si decides que todo tu experimento fue un fracaso y prefieres eliminar esta característica, ya no puedes hacerlo porque alguien depende de esto.

Las restricciones de carga son la capacidad de restringir el acceso a tu proyecto, de especificar el tipo de proyecto que puede acceder a esto. Podría ser tan simple como si tienes, por ejemplo, Angular y React en tu repositorio, puedes decir que las bibliotecas de Angular no deben cargar las bibliotecas de React. Pero, ¿qué pasa si solo tienes un proyecto? ¿Deberías seguir usando los monorepos? La respuesta es simple. Absolutamente, sí.

También proporcionan generadores potentes. Normalmente, cuando comienzas un proyecto, lo haces con una CLI que genera y estructura proyectos para ti. La mayoría de las veces está bien. Pero a menudo no lo está. Por eso hay tantos proyectos de plantilla que te llevan un paso adicional. Ahora, imagina si pudieras configurar tu CLI para generar cosas como te gustan, con pruebas unitarias, con pruebas de extremo a extremo, con tu configuración de gestión de estado de la forma que te gusta, con todas las utilidades y aplicaciones tal como te gusta. Con NX, por ejemplo, tienes estos generadores potentes donde realmente puedes configurar todo y no solo en el momento de la inicialización, sino también cada vez que creas un nuevo componente o una nueva función o un nuevo proyecto puedes especificar cómo debería verse.

También te brinda la capacidad de migrar cosas de manera sencilla. Así que imagina que hay una nueva versión de tu framework BelowIt y, por supuesto, hay algunos cambios importantes. Normalmente, tendrías que ir a tu código y solucionar todos esos problemas y arreglarlos manualmente. Con generadores, con migración automatizada, puedes simplemente ejecutar la migración y solucionará todo esto por ti. Y finalmente, tenemos herramientas consistentes. No sé tú, pero para mí siempre fue molesto cuando cambiaba entre diferentes frameworks y luego tenía que recordar si era NPM start o NPM serve o si era NPM develop. Y no se trata solo de servir aplicaciones. Todos estos comandos tienen diferentes parámetros y formas diferentes de ejecutarse. Por lo tanto, las herramientas consistentes crean un envoltorio alrededor de estos comandos para que siempre puedas ejecutar los comandos de la misma manera, independientemente del framework que esté debajo o si es next o next o si es Cypress o ESLint y no solo son comandos, son parámetros que siempre son los mismos. Por lo tanto, solo necesitas aprender un conjunto de comandos. Incluso esto no tienes que hacerlo porque aquí lo que olvidé mencionar es que también proporcionamos extensiones para VS Code que te brindan esta agradable representación gráfica de todos los generadores para que puedas encontrar fácilmente el generador que te gusta y te brindará información sobre todos los parámetros que necesitas pasar. No tienes que recordar nada.

Entonces, recapitulemos. Los monorepos brindan claridad al proporcionarnos análisis del espacio de trabajo y visualización de gráficos. Nos brindan velocidad al aprovechar el almacenamiento en caché local y remoto, la orquestación de tareas, la detección de nodos afectados y la ejecución de tareas distribuidas.

Y finalmente, hacen nuestra vida de desarrollo más fácil porque nos brindan intercambio de código, colocación de código, generadores potentes, herramientas consistentes y restricciones de código. Si quieres saber cómo se comparan entre sí diferentes soluciones de monorepos, puedes dirigirte a monorepos.tools, que te ofrece una comparación detallada con todas las características enumeradas. Y este sitio web de código abierto ha sido mantenido por los creadores de populares soluciones de monorepos. O, si no quieres perder tanto tiempo, puedes simplemente confiar en mi palabra y usar NX. Y si te preguntas si esto es lo que finalmente te convertirá en un desarrollador 10x, ¿por qué conformarte con 10x cuando puedes ser un desarrollador NX? Gracias y disfruta de la conferencia. Muy bien. Vamos un poco retrasados, así que solo vamos a responder una pequeña pregunta de la sesión de preguntas y respuestas. Pregunta de un anónimo. ¿Qué pasa con tener múltiples versiones del mismo framework, como una aplicación con React 17 y React 18? Todas las soluciones proporcionan la posibilidad de tener módulos de nodo agrupados. Esto significa que cada proyecto puede tener su propio package JSON y su propio conjunto de dependencias. Por lo tanto, puedes tener en un proyecto React 16, en otro React 17 y en el tercero React 18. Por supuesto, te recomendamos que intentes nivelar todas esas versiones para que tengas un lugar central donde se establezcan todas las dependencias. Pero si eso no funciona por alguna razón, simplemente puedes agruparlas con tus proyectos. Todo está bien. Todo está bien. Bueno, muchas gracias, Miro. Gracias. Un gran aplauso para Miro. Y ahora pasaremos a nuestro próximo ponente.