Las decisiones que se toman en el arranque de un proyecto, son piezas fundamentales de su éxito en las primeras versiones de la misma. Dependiendo de ellas, podemos encontrarnos con escenarios que pongan en riesgo la escalabilidad y mantenibilidad, o que por el contrario, catapulten la implementación y el despliegue.
Ahora bien, no todos los escenarios son siempre los mismos, por lo que las decisiones que tomemos no van a dar respuesta a las mismas necesidades, y por tanto, no existe una solución estándar.
En el ecosistema actual FrontEnd podemos ver un caso muy claro, no sólo en cuanto a qué tecnología utilizar, sino a cómo se construye la misma.
En este artículo, mostraremos los puntos que hemos tenido en cuenta y qué factores influyen en la toma de decisiones técnicas.
⚠️ Este escenario no tiene por qué coincidir con el tuyo, por lo que es importante que no te quedes con la tecnología elegida, sino con el proceso.
En las últimas semanas nos hemos enfrentado al reto de arrancar una nueva aplicación en React. Esto no difiere en gran medida de nuestro trabajo diario. Gran parte del equipo trabaja con esta tecnología, sin embargo, no arrancamos proyectos de cero constantemente.
Actualmente existen varias herramientas para React que nos permiten arrancar un proyecto como son el caso de Next.js, Remix, Create React App; o incluso podemos importar la librería directamente en un fichero html y hacer la configuración de Webpack/Vite/Rollup.js pertinente.
Cualquiera de las soluciones sería totalmente válida, a pesar de ello, cada una va a implicar una serie de características con las que tendremos que lidiar.
En este caso las especificaciones del producto eran claras: se necesita un producto creado con React que permita el uso de Custom Service Workers, que consuma una API de terceros, cuyo bundle tenga el menor tamaño posible, que la compilación permita cierto nivel de personalización, pero que además pueda ser manejado por personas sin un “expertise” elevado.
Consideramos de vital importancia antes de abordar una solución de software: entender al consumidor de la aplicación; qué perfiles, experiencia y afinidad van a tener con la tecnología las personas encargadas de crear y mantener el sistema; y por último, la cadencia de entrega que va a requerir.
Partimos de la base que se trata de una aplicación muy pequeña que podría (o no) escalar, y que debe estar definida como una Progressive Web App (PWA), la cual no va a ser usada sin autenticación. Esto nos lleva a deducir que no vamos a necesitar Server Side Rendering (SSR) y dado que tampoco queremos tener una curva de aprendizaje sobre frameworks, nos decantamos por descartar Next.js y Remix para este proyecto.
A pesar de que estas dos tecnologías son bastante estándar y nos aportan una solución muy buena para contenido que debe ser indexado por “crawlers”, además de un sistema de enrutado, las personas necesitan tener un conocimiento mínimo de cómo las librerías manejan esto.
Además en caso de requerir pivotar porque nos hemos equivocado, tendríamos que asegurarnos de no haber creado una dependencia sobre la librería. Arrancar un proyecto con este tipo de pensamiento en mente constantemente, puede llevar a ralentizar mucho el desarrollo, lo cual nos lleva a evitar directamente esa posibilidad.
Siempre podemos apoyarnos en técnicas de diseño de software como el wrapping, para separar la definición técnica (uso de librerías) del código más puro relativo al negocio (dominio).
Esto nos deja con las opciones de utilizar CRA, o en su lugar, montar una aplicación básica con React usando Webpack o Vite.
En el pasado, hemos utilizado CRA en muchas ocasiones y nos ha funcionado a la perfección en versiones muy tempranas de desarrollo, sin embargo, en el momento en el que necesitábamos hilar fino en la generación del bundle, o en cómo personalizar ciertas funcionalidades, nos hemos visto en la necesidad de ejecutar un eject de la aplicación en lugar de utilizar los react-scripts definidos en la versión por defecto.
Cuando esto ocurre somos capaces de ver la complejidad que tiene el código que está por debajo. Dado el contexto que tenemos, sabemos que este caso se va a dar más temprano que tarde, y por tanto, es un gran riesgo que invirtamos semanas en tratar de configurar algo sin hacer un eject, hasta que finalmente consideremos que no queda otra alternativa, y por tanto nos veamos obligados a “pasar por el aro” y heredar esta complejidad.
Por último, nos queda la opción de hacerlo desde 0, utilizando solamente las dependencias que necesitamos, pero requiriendo tener un conocimiento más allá de React y tener cierto dominio sobre las herramientas de empaquetado.
Ya sabemos que Webpack es una herramienta fantástica que ofrece infinidad de opciones de compilación, sin embargo, para las personas sin experiencia previa se convierte en un “galimatías de código” poco amigable a su lectura, y más complicado aún a su entendimiento.
Es por ello que ojeamos Vite.js. Actualmente esta librería es usada por Vue3 como bundler por defecto. Su tiempo de ejecución es considerablemente menor que el de Webpack, y por otra parte, el tamaño de los bundle que genera es ligeramente más pequeño.
Por otra parte, funciona a través de plugins que, aunque requieren de cierto conocimiento de los pasos a realizar, éstos proveen mayor información de qué se está haciendo, por ejemplo: registrar una PWA, convertir modules a commonjs, copiar estáticos, etc.
Realmente no sabemos si las decisiones tomadas son las correctas, y jamás sabremos que habría pasado si para este escenario nos hubiésemos decantado por otras opciones. Pero consideramos que el proceso de evaluación tecnológica, puede ayudar a muchas personas en su día a día a evaluar los escenarios, y considerar en qué factores nos podemos basar.
Nosotros nos hemos basado en los siguientes puntos:
Esperamos que este post te ayude en futuras soluciones y que de alguna forma, te permita desempeñar tu trabajo de una forma más eficiente.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
