Desarrollando como Google / Facebook / Microsoft (Monorepos)

# ¿Qué es un monorepo? La explicación más sencilla y rápida que se puede dar sobre el tema, no es más que tener un grupo de proyectos en un solo repositorio. ¿Pero por qué hacer semejante cosa?, pues a continuación mostramos la fortaleza de tener tus proyectos en un solo repositorio: - ¿Cuantas veces les ha pasado que tienes que reutilizar código de una aplicación en otra?. En el mejor de los casos creamos una librería para compartir el código entre dichas aplicaciones, pero lo que realmente pasa es que sencillamente se copia el código y se pega en el otro proyecto. - ¿Cuantos tienen proyectos que cuentan con más de un frontend, dada las características del proyecto? - ¿Cómo comparten código entre proyectos que utilizan diferentes frameworks?. Digamos que tienes un proyecto en **Angular** y otro en **React**, ¿cómo unirlos o compartir su código? Pues todas estas interrogantes y problemas, pueden ser de alguna manera abordados y solucionados con un **monorepo**. Primeramente decir, que la idea de tener un **monorepo**, no es que ahora todos nuestros los proyectos los vamos a encapsular en un solo repositorio (para nada es la solución). Pero definitivamente, si tienes un proyecto en el que cuentas con más de un frontend, creo que es una buena idea migrar a un **monorepo**. ## Pequeña historia de por qué llevamos Binary Coffee a monorepo Al iniciar y teniendo como objetivo principal compartir contenido, iniciamos luego de una pequeña investigación con **strapi** en el backend y angular en el frontend como tecnologías core del proyecto. Todo fue de maravilla al principio, hasta que identificamos que no podíamos utilizar la administración de **strapi** para crear los contenidos, no porque no se pudiera, sino porque en esta administración se encuentran todas las configuraciones y parámetros esenciales de la API, de tal manera que cualquiera sin desearlo podría cambiar y BUM, adiós producción. Pues en este contexto se creó otro frontend, para la administración del sitio. Algunos pueden discrepar con nosotros sobre porqué no hacerlo sobre el mismo proyecto del frontend y la respuesta es sencilla, eran modelos y lógicas completamente distintas que no compartían mucho en común y desde el punto de vista de un cliente, no era necesario que tuviera toda una administración atada a él. Así que finalmente todo quedó: como **frontend** y **admin-frontend**. Pero rápidamente vimos que muchos de los peticiones y la estructura de ambas aplicaciones eran la misma y empezamos a copiar y pegar de uno a otro (no nos crucifiquen). ## ¿Cómo se acabó la pesadilla del copia-pega en Binary Coffee? Unimos los proyectos en un **monorepo**. Ahora contamos con los proyectos en un mismo repositorio, y una sección de librerías con la cual todo aquello que identificamos como acciones comunes entre los proyectos, se llevan a una librería, evitando el copia-pega y repetición de código. ## ¿Qué utilizamos para unir los proyectos en un monorepo? Pues no crean ni por un segundo que esto fue, copia el proyecto pegalo y copia el otro y pegalo, y PUM ya tienes **monorepo**. No, no es así, para Angular contamos con una herramienta que se llama **NRWL**, que nos hace la vida completamente fácil. Esta herramienta cuenta con funciones que pueden convertir proyectos existentes en un **monorepos** o iniciar desde cero nuestro proyecto en un **monorepo** si sabes que en el futuro llegaremos a tener más de un frontend en el proyecto. Pero lo más interesante de esta herramienta es que no solo es para **Angular**, también lo podemos usar para **React**, **Vue** o simplemente una aplicación **javascript nativa**. He incluso más, podemos unir en un solo **monorepo** a proyectos de diferentes tecnologías. Pues sí, como lo escuchas, ya puedes ligar tu proyecto **React** con el de **Angular** y con el de **Vue** y compartir librería entre ellos. Definitivamente está herramienta se merece un artículo para ella sola y no hablaremos mucho del tema, solo les dejaremos los enlaces para si desean echarle un ojo y probarla, por otra parte si quieren verla en acción, pueden echarle un ojo al código de [Binary Coffee frontend](https://github.com/dcs-community/dcs-frontend), que como mencionamos ya la estamos usando. ## ¿Existen herramientas similares para otros lenguajes? Pues si, existen herramientas para tener nuestros proyectos en un **monorepo**. Si tienes curiosidad por ver algunas de ellas echale un vistazo a este [link](https://github.com/korfuri/awesome-monorepo) que contiene un buen listado de herramientas sobre el tema. Además agregar, que muchas de las herramientas que usualmente utilizamos, tienen soporte para **monorepos**, como es el caso de git. ## Conclusiones - Como mencionamos anteriormente, **monorepo** no es la solución a todos los problemas, pero es una buena solución a proyectos medianamente grandes donde quieres de manera fácil reutilizar código entre ellos. - No todo es color de rosas con el **monorepo**, actualmente enfrentamos problemas para identificar que proyecto fue el afectado con los cambios y en respuesta a ello solo desplegarlo y no así con un despliegue generar de todos los proyectos en cada push. Pero ya estamos identificando maneras de resolver el problema y posiblemente próximamente compartiremos en un nuevo artículo cómo hicimos para esto. - De momento estamos contentos con los resultados, y vemos muchas ventajas en el uso de **monorepos**, con más tiempo volveremos a dar un resumen y nuestras bien justificadas conclusiones. ## Enlaces - [nrwl.io](https://nrwl.io) - [Binary Coffee frontend](https://github.com/dcs-community/dcs-frontend) - [strapi](https://strapi.io) Bueno, esto es todo, así que ya sabes, deja en los comentarios tus opiniones y que crees sobre el tema. > Happy coding!