Saltar al contenido principal
Volver a todos los artículos
Tecnología y Desarrollo5 min de lectura

La Arquitectura de Mi Blog: Por Qué Descarté WordPress y Abracé lo Estático

Descubre por qué elegí una arquitectura estática (Jamstack) para mi blog personal, abandonando los sistemas tradicionales. Te cuento mi stack tecnológico y cómo soluciono funcionalidades dinámicas como comentarios o búsquedas.

Cuando decidí que necesitaba un blog, mi primer instinto no fue ir a WordPress, Medium o Substack. Como constructor, mi impulso es siempre el mismo: ¿cómo puedo tener control total, máxima performance y una experiencia de desarrollo que no me haga querer arrancarme los pelos?

La respuesta fue clara: construir mi propia plataforma. Pero no desde cero en el sentido tradicional. Elegí un camino más inteligente, moderno y, francamente, superior para mis necesidades: una arquitectura estática.

El problema con el "Dinamismo" por defecto

He trabajado con WordPress, Drupal y otros CMS dinámicos durante años. Son herramientas potentes, pero vienen con un equipaje que ya no estoy dispuesto a cargar:

* Base de datos constante: Cada visita a una página genera múltiples consultas a una base de datos. Es un cuello de botella inherente. * Mantenimiento y actualizaciones: El infierno de los plugins. Un día todo funciona, al siguiente una actualización de un plugin rompe el sitio o, peor, abre un agujero de seguridad. * Complejidad innecesaria: Para un blog, ¿realmente necesito un servidor de aplicaciones y una base de datos corriendo 24/7 solo para servir texto e imágenes que rara vez cambian?

Quería escribir y publicar, no pasarme los fines de semana depurando un `error establishing a database connection`.

Mi Elección: La Arquitectura Estática (Jamstack)

La idea es simple pero revolucionaria: en lugar de generar las páginas cada vez que alguien las visita, las pre-construyo todas una sola vez. El resultado es un conjunto de archivos HTML, CSS y JavaScript puros y listos para ser servidos.

Los beneficios son brutales:

1. Velocidad Absurda: Servir un archivo HTML desde un CDN (Content Delivery Network) es lo más rápido que existe. No hay procesamiento en el servidor, no hay consultas a la base de datos. Hablamos de tiempos de carga inferiores a un segundo, en cualquier parte del mundo. 2. Seguridad a Prueba de Balas: Mi "backend" no es más que una carpeta de archivos estáticos. No hay base de datos que hackear, no hay un panel de admin que atacar. La superficie de ataque es prácticamente nula. 3. Escalabilidad Infinita (y Barata): ¿Recibo un pico de tráfico de 100,000 visitas por un post viral? No hay problema. Los CDNs están diseñados para eso. Y el costo es marginal o incluso cero en muchos proveedores. 4. Experiencia de Desarrollo Superior: Aquí es donde todo cobra sentido para mí. Escribo mis posts en Markdown, uso Git para versionar cada cambio, y aprovecho todo el ecosistema moderno de JavaScript. Es un flujo de trabajo limpio, controlable y repetible.

Mi Stack Tecnológico

No hay una sola forma de hacerlo, pero este es mi combo ganador:

* Generador de Sitio Estático (SSG): Uso Astro. Es increíblemente rápido porque envía cero JavaScript al navegador por defecto. Es perfecto para sitios de contenido como un blog, pero me permite añadir interactividad (componentes de React, por ejemplo) solo donde la necesito. * Contenido: Puros archivos `.md` (Markdown) dentro de mi repositorio de Git. Esto es oro. Puedo escribir en cualquier editor de texto (como VS Code), tengo un historial completo de cada cambio y todo mi contenido está respaldado y versionado junto con el código. * Hosting y Despliegue: Vercel. Conecto mi repositorio de GitHub a Vercel y la magia ocurre. Cada vez que hago un `git push` a la rama principal, Vercel automáticamente detecta el cambio, construye el sitio y lo despliega en su CDN global en segundos. Es un flujo de trabajo impecable.

Potenciando el Sitio Estático: ¿Y lo dinámico?

"Estático" no significa "aburrido" o "limitado". Simplemente desacoplamos el frontend de los servicios. Así es como resuelvo las partes "dinámicas":

* Comentarios: En lugar de gestionar mi propio sistema, uso Giscus. Es una solución brillante que conecta los comentarios de un post con una Discusión de GitHub. Mantiene todo dentro del ecosistema de Git y es gratis. * Búsqueda: Para un blog pequeño o mediano, una búsqueda en el lado del cliente es suficiente. Genero un índice de todo mi contenido durante la construcción del sitio y uso una librería como `Fuse.js` para que la búsqueda se ejecute directamente en el navegador del usuario. Es instantánea. * Formularios: Uso un servicio como Formspree. Incrusto un formulario HTML simple que apunta a su endpoint, y ellos se encargan de recibir los datos y enviármelos por email. Cero configuración en mi lado. * Analíticas: Me he alejado de Google Analytics. Uso Plausible Analytics, una alternativa ligera y centrada en la privacidad que no ralentiza mi sitio.

¿Vale la Pena para Ti?

Seamos directos. Esta arquitectura no es para todos. Si no te sientes cómodo con Git, la línea de comandos o editando archivos de configuración, una solución como WordPress.com o Ghost puede ser más adecuada.

Pero si eres un desarrollador, escritor técnico o simplemente alguien que valora el control, la velocidad y un flujo de trabajo limpio, te animo a que lo pruebes. La inversión inicial de aprendizaje se paga con creces en tranquilidad, rendimiento y el placer de tener una plataforma que es verdaderamente tuya.

Para mí, la elección es obvia. He cambiado el mantenimiento y la incertidumbre por velocidad, seguridad y un proceso que disfruto. Y eso me deja más tiempo para lo que realmente importa: escribir.

Escrito por Samuel Moreno

Socio y Desarrollador en Sinergia Barcelona.

La Arquitectura de Mi Blog: Por Qué Descarté WordPress y Abracé lo Estático | Un paseo por la vida