"OK", es mejor que "Perfecto"

Durante mi carrera como software engineer, he visto (y he sido parte también) de muchas discusiones sobre "cómo hacer las cosas bien" o "cómo debemos adherirnos a las buenas prácticas establecidas por la industria". Gracias al tiempo que he pasado en Zapier (¡estamos contratando!) he podido replantear muchos de esos pensamientos, acá va la historia.

El proyecto en el que estoy trabajando con mi equipo ha tenido muchos "contratiempos" y retrasos, la migración de datos en la que estamos trabajando es supremamente compleja con muchos edge cases que siempre retrasan más y más la entrega. ¿Y bueno, qué proyecto ha terminado antes del cronograma? (De hecho, deben haber varios, pero desde mi experiencia son más los proyectos que fallan el primer estimado).

Uno de los más grandes "unknown unknowns" del proyecto fue: "¿cómo replicar el viejo sistema de redireccionamiento en el nuevo sistema?", y bueno, los requerimientos para este feature se ven más o menos así:

  • Necesitamos Server Side redirects (en vez de Client Side redirects) por temas de SEO.
  • Los usuarios finales (no técnicos) del sistema deben ser capaces de crear redirects a su gusto sin involucrar al equipo de ingeniería.

El reto

Actualmente, estamos usando la última versión estable de Next.js - 9.4.4 al momento de escribir este post, pero no hay forma de hacer server side redirects desde Next.js sin usar un Custom Server. Afortunadamente, el equipo de Next.js ya está trabajando en dar soporte a redirects nativamente.

  • Ese nuevo feature: soportar redirects nativamente, no ha sido publicado en NPM (pero ya fue solucionado en su versión v9.4.5-canary.21).
  • Otro paquete (next-transpile-modules) de NPM del que depende nuestro sistema, no es compatible con la versión Canary de Next.js que necesitamos
  • Ya existe un Pull Request # 89 que intenta solucionar el problema de compatibilidad

La solución

Nuestro objetivo es el de eliminar los unknowns de la ecuación tan rápido como sea posible, entonces depender de terceros (Next.js y next-transpile-modules) no es una solución viable ya que el siguiente release puede pasar en un día, una semana, un mes, o seis meses.

Decisión uno

Decidimos usar Next.js en su versión `v9.4.5-canary.30` ya que en este punto la API para los redirects es estable y está fuera de Experimental como mencioné arriba.

Con esto, tendríamos las siguientes opciones sobre la mesa:

  1. Hacer un fork de next-transpile-modules, ayudar con el fix que ya existe, esperar a que el autor del módulo haga merge de los cambios y que publique la nueva versión con el fix.
  2. Hacer un fork de next-transpile-modules y mantenerlo como un paquete privado en Zapier, tipo @zapier/next-transpile-modules, publicarlo en NPM y consumirlo en nuestro proyecto. Esto nos ahorraría tiempo porque no tenemos que esperar por una aprobación de un tercero para que nuestros cambios sean publicados, pero no es tan rápido como necesitamos porque aunque podemos hacer npm link para probar nuestros cambios de manera local, publicar un paquete requiere tiempo.
  3. Copiar el código fuente del módulo en nuestro proyecto, hacer el fix y consumir el paquete.

De las 3 opciones mencionadas, la que está más lejana a las "buenas prácticas" por mucho es la opción número 3 porque:

  • Perdemos la habilidad de obtener cualquier nuevo fix que se haga en next-transpile-modules
  • Estamos duplicando código, en este momento tendremos 2 versiones casi idénticas de next-transpile-modules, la nuestra y la "original" (desde donde copiamos el código)

Decisión dos

Hacer una copia local de `next-transpile-modules` y hacer el fix del paquete de manera local.

👉 Conclusión 👈

Después de haber tomado las dos decisiones mencionadas arriba, ya tenemos Server Side redirects funcionando en Next.js sin problema. Ahora bien, preguntémonos:

  • Bajo los "estándares" de desarrollo de software actuales, ¿Está bien lo que hicimos? La respuesta es NO. Estamos usando una versión Canary en nuestro proyecto, además de tener un parche local a un paquete de un tercero.
  • ¿A nuestros usuarios finales, les importa qué versión de Next.js estamos usando? (entran risas), ABSOLUTAMENTE NO, a los usuarios les importa que nuestro software les haga la vida más fácil. Es nuestra tarea proteger a nuestros usuarios de todas las complejidades.

Las "buenas prácticas" no son más que patrones con los que otros han tenido éxito, debemos tenerlas en cuenta, pero no debemos sacrificar a nuestros usuarios por cumplir esas "buenas prácticas". Las "buenas prácticas" de hoy puede que sean obsoletas mañana y está en nuestras manos definir si esas "buenas prácticas" son tan "buenas" para resolver nuestros problemas.

👋🏼 Gracias por leer - hasta la próxima!

Suscríbete al newsletter

Solo lo necesito para enviarte información sobre mi blog y/o el contenido que cree.

© 2020-2021 Alejandro Nanez. All rights reserved.