Binary Coffee

Desarrollando como Google / Facebook / Microsoft (Monorepos)

angular git monorepo
# ¬Ņ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!
Opiniones