Programando un blog aprenderás esto (pirobits v3)

Siempre me ha gustado utilizar mi blog como side-project para experimentar y aprender con diferentes tecnologías, explorar ideas y contarte mis aprendizajes en el camino de construir productos y herramientas como ingeniero de software. Ahora toca plantear una nueva versión.

Mi blog (pirobits) ha pasado por diferentes etapas: primero comencé con ficheros estáticos servidos con AWS S3, luego con utilicé EC2, usé generadores de estáticos como Hugo, y finalmente terminé utilizando Next.js para aprender los React Server Components y tener una API en un VPS.

Cada etapa ha tenido sus pros y sus contras, que más adelante analizaré en profundidad y que me han permitido disfrutar aprendiendo. Al final la evolución de cualquier producto (o empresa) suele venir definida por las necesidades de los usuarios o del mercado. En mi caso el blog va evolucionando conforme a mis necesidades tanto de aprendizaje, como de construir una plataforma donde compartir todo esto que hago como hobby.

Al principio con pirobits simplemente quería volver a contar lo que aprendo, luego quise tener una API para tener una newsletter y poder añadir cierta interactividad al blog... y ahora, conociendo las ventajas e inconvenientes de cada alternativa, quiero tener un producto que esté construido con tecnologías que conozco bien, que sea simple en su diseño, que pueda añadir funcionalidad fácilmente y que tenga procesos automatizados para optimizar mi tiempo.

También como siempre digo, me gusta construir por mera diversión y aprendizaje y quiero que sea mi propio producto con el que puedo jugar y experimentar. Vienen muchas novedades en las próximas semanas, por lo que recuerda suscribirte a la newsletter.

Primera versión: ficheros estáticos

En la primera versión quería únicamente poder escribir lo que aprendía y construía, por lo que lo más simple era probar un generador de estáticos. Aquí probé a renderizar yo mismo el contenido por experimentar, pero había que tener en cuenta bastantes detalles por lo que la mejor opción era utilizar un generador de estáticos. Aquí estuve probando Hugo, que está desarrollado en Go, tiene una gran comunidad y es muy completo.

Para servir los estáticos exploré tanto opciones cloud serverless, donde descubrí que hay partes que estaban algo verdes y no me terminaban de convencer, luego exploré almacenamiento en AWS con S3 y EC2, aunque por coste una instancia VPS en cualquier otro proveedor con un NGINX era mucho más barato. Además, esto me permitió probar herramientas para configurar un servidor de forma remota.

He valorado la opción de utilizar de nuevo un generador de estáticos como pueden ser Hugo, Zola o Lume, pero ahora mismo no termina de convencerme por varios motivos:

• No quiero hacer rebuild/redeploy tras cada publicación.
• No quiero tener que mantener otro proyecto para la API.
• Aunque me gustan las opciones serverless, no lo contemplo para ciertos proyectos donde un VPS de 5$ te sirve perfectamente.

Segunda versión: Next.js

Tras un tiempo trabajando con los ficheros estáticos, y ahora quería mejorar tanto el diseño del blog como poder añadir cierta interactividad al blog. Como conozco muy bien React desde hace varios años y he trabajado en un proyecto con SSR (server-side-rendering) propio, quería explorar las ventajas de utilizar herramientas como Remix.js o Next.js.

De Remix.js me encantó su filosofía, aunque me di cuenta que tenía que desarrollar yo mismo diferentes partes. Por tanto, me decidí a utilizar Next.js para aprender los React Server Componentes. Este es un framework que me encanta por las optimizaciones que trae, cómo está estructurado... aunque también tiene algunos problemas que comenté en este otro post.

Desde luego si quieres construir un producto que sea un SPA, Next.js es una opción muy interesante. En mi caso tras trabajar con Next.js en esta última versión de mi blog, pienso que no ha sido la mejor decisión ya que al final lo utilizo para renderizar contenido que es estático en su mayoría y por limitaciones de la herramienta, he pasado más tiempo haciendo workarounds que construyendo el producto. En cambio, he construido otros productos que son SPAs con Next.js y los React Server Components y estoy encantado con el resultado.

Como siempre digo, la mejor solución a cada problema siempre es relativa, y a veces simplemente hay que probar y equivocarse hasta encontrar la mejor solución.

Tercera versión: eligiendo el stack

Hoy día existen miles de herramientas entre las que podemos elegir como "web framework": desde más alto nivel como a más bajo nivel. También existen medios como Medium, Substack o Ghost (que es open source), que te lo dan todo hecho pero en mi caso, no encajan con mis necesidades. Me ha faltado explorar Astro, que me ha llamado la atención la idea aunque veo una idea muy parecida a Next.js.

Mi principal problema es que muchos procesos del blog son manuales y no son óptimos, por lo que quiero automatizar diferentes tareas que realizo de forma manual. Además, no quiero mantener la base actual ya que tiene ciertas limitaciones que me impiden añadir nueva funcionalidad.

El objetivo es crear algo simple que me permita renderizar el contenido de forma dinámica, que el despliegue y la publicación esté completamente automatizada, de forma que pueda centrar mi tiempo en escribir los posts de forma eficiente.

Por tanto con la tercera versión voy a utilizar la opción clásica: utilizar un web framework que tenga un sistema de plantillas, incluya una API y yo implementaré las funcionalidades que necesito. Lo bueno es que aunque requiere algo de tiempo inicial de configuración, luego es una base fácil de mantener, modificar o ampliar.

En el siguiente post hablaré sobre la arquitectura concreta en la que estoy trabajando y los diferentes retos que esto genera. Al final cualquier alternativa tiene sus pros y sus contras. Elige la que sea más cómoda para tí y si te equivocas aprenderás. En la mayoría de casos, podrás cambiar de decisión y más si es al inicio de un producto que evolucionará rápidamente. Por tanto como se dice... fail fast.