Monorepos: Boosting Development Efficiency

Mi nombre es Philip Fulcher. Tengo unos cinco minutos para hablarles sobre monorepos. Así que hablemos de ello. Pero, ¿de qué hablamos cuando hablamos de monorepos? ¿Qué es siquiera un monorepo? Y algunas personas podrían decir, oh, eso es como cuando Google solo tiene un repo para toda la empresa, ¿verdad? Y eso no es de lo que estamos hablando. Esa es una escala de monorepo que es inviable para la mayoría de las personas. Probablemente no seas Google.

Tal vez un monorepo es cuando simplemente lanzas todo tu código en un solo repo y luego lo resuelves más tarde. Y eso definitivamente no es algo que queramos hacer. Eso va a causar todo tipo de problemas. Así que tengamos una buena definición práctica de un monorepo es un único repositorio que contiene múltiples proyectos distintos con relaciones bien definidas. Y de lo que realmente quiero hablarles hoy es sobre este último elemento. ¿Qué queremos decir con relaciones bien definidas?

Pensemos en las relaciones en el código en términos de distancia. Así que lo más cercano que dos piezas de tu código pueden estar relacionadas es simplemente código que está en diferentes archivos. Tienes un componente de botón. Tiene todas tus clases de Tailwind que te mantienen en la marca. Y luego vas a importar ese botón en tu formulario para poder usarlo realmente. Y ahora hay una dependencia entre el formulario y el botón. El formulario no funciona sin el botón. Y hacemos esto todo el tiempo. Y damos por sentado lo bien que funciona esta relación para nosotros. Cuando haces un cambio en el archivo del botón, puedes ver inmediatamente el cambio en el formulario. Tienes ya sea una representación en el navegador, o tienes un error de compilación. Tal vez tienes una suite de pruebas ejecutándose. Eso te va a decir que hay un problema, o incluso errores de lint. Pero puedes entender el impacto de tu cambio inmediatamente. Y debido a eso, la iteración es realmente rápida. Haces un cambio. Puedes verlo. Puedes responder a ello, arreglarlo, pasar a lo siguiente. Pero te estás moviendo rápido.

Veamos qué sucede si llevamos esa relación un paso más allá. Y pensemos en el código en paquetes. Y si importamos ese botón de un sistema de diseño que publica nuestra organización, esto se siente muy similar a lo que acabamos de hacer. Desafortunadamente, hemos aumentado la distancia entre estas dos piezas de código. Y lo que eso hace es que entender el impacto del cambio sea lento. Para hacer un cambio en el botón, hago un cambio dentro del sistema de diseño. Tengo que pasar por algún tipo de proceso de compilación o empaquetado y luego publicación, y luego tengo que consumir la última versión del paquete para ver el cambio final en mi formulario. Y eso es realmente lento, incluso cuando estás trabajando solo en una sola máquina.

Cuando hablamos de cruzar barreras de equipo allí, tu equipo de sistema de diseño tiene que hacer el cambio, fusionar, cortar una versión, publicar. Tienes que consumir la última versión. Esa es una comprensión realmente lenta del impacto del cambio del equipo de sistema de diseño. Y por lo tanto, la iteración es muy lenta. Demos un paso aún más allá en términos de relación entre códigos y pensemos en APIs. Tu front end tiene una dependencia implícita de tu back end. No funcionará sin el back end en la mayoría de los casos. Y entonces, si tienes una API que se desarrolla, es como, todos acordamos al principio del sprint que este endpoint de API se llamaría Contact Create, ¿verdad? Bueno, salió como Contact Init. No sé si alguna vez has tenido cambios en tu API de back end que suceden así a mitad de sprint. Pero ahora esta relación es aún más lenta de lo que hemos hablado antes.

Porque ahora es el mismo proceso del que hablamos de fusionar un PR, y empaquetar, y empaquetar. Pero ahora estás hablando de un despliegue completo antes de que pueda realmente interactuar con esta nueva API de back end y confirmar que los cambios realmente funcionan. Y esa iteración es increíblemente lenta. Los monorepos, cuando pones esos múltiples proyectos todos juntos en un solo repositorio, van a reducir la distancia de tus relaciones. Ese cambio que quieres hacer en tu botón o tu API de back end ahora está co-ubicado con el código de front end que lo va a consumir. Y eso solo significa que está en el mismo repo, y que podemos importarlo, y podemos usar todas las herramientas realmente buenas que nos ayudan a entender el impacto de ese cambio. Y con algunas herramientas útiles de una herramienta de monorepo, podemos entender esas relaciones y realmente rastrearlas para determinar qué ha sido afectado por nuestros cambios. Así que cuando hablamos de poner todos tus proyectos o muchos, muchos proyectos en un solo monorepo, sentimos que estamos haciendo un gran cambio. Pero en realidad no estamos cambiando las relaciones entre los proyectos que ya tenemos. Lo que estamos haciendo es hacerlas explícitas. Nos aseguramos de saber que esa relación existe y cómo entendemos el impacto de los cambios a través de esa relación. Y por eso, esas relaciones están bien definidas. Y a través de eso, los monorepos te van a ayudar a moverte más rápido. Si quieres saber más sobre monorepos, por favor visita monorepo.tools. Te ayudará a entender el concepto de monorepo así como muchas de las herramientas que están disponibles en el espacio. Creo que la mejor herramienta para que gestiones tu monorepo hoy es NX.