Cómo migré de WordPress a un blog en Go
Durante años este blog corrió sobre WordPress. Funcionaba. Hacía lo que tenía que hacer. Pero con el tiempo la relación se fue desgastando hasta que un día decidí que era suficiente y lo tiré todo para empezar de cero. Este post cuenta por qué, cómo y qué he aprendido en el proceso.
Por qué dejé WordPress
WordPress es un buen software. Lo digo sin ironía. Ha democratizado la publicación web de una forma que ninguna otra herramienta ha conseguido. Pero para un blog personal con diez posts, WordPress es como usar un camión articulado para ir a comprar el pan.
Mi instalación tenía PHP 8.4, MySQL, Nginx con FastCGI cache, un tema que había modificado hasta dejarlo irreconocible, seis plugins de los cuales solo entendía tres, y un panel de administración con más opciones que un avión comercial. Todo eso para servir texto con alguna imagen.
Los problemas concretos que me empujaron a salir:
Rendimiento: incluso con FastCGI cache, la primera visita después de un cache miss ejecutaba PHP, consultaba MySQL, cargaba plugins, evaluaba el tema y generaba HTML. Para un post estático. Absurdo.
Seguridad: WordPress es el CMS más atacado del mundo porque es el más usado. Cada semana hay una actualización de seguridad de algún plugin. Si no actualizas, estás expuesto. Si actualizas, puede romperse algo. Es un ciclo agotador.
Complejidad innecesaria: no necesito un editor visual. No necesito taxonomías avanzadas. No necesito un sistema de usuarios con roles. No necesito WooCommerce, Yoast SEO ni Jetpack. Necesito escribir Markdown, convertirlo a HTML y servirlo.
Las alternativas que descarté
Antes de ponerme a programar, evalué las opciones existentes.
Hugo: el candidato más obvio. Generador estático en Go, rápido, potente, bien documentado. Lo usé durante una semana y me gustó la filosofía pero no el workflow. Tener que compilar el sitio cada vez que publicas un post y subir los ficheros generados añade fricción. Quería algo que leyera el Markdown directamente y lo sirviera.
Jekyll, Eleventy, Astro: misma categoría que Hugo. Generadores estáticos con paso de compilación. Descartados por la misma razón.
Ghost: elegante, moderno, bien diseñado. Pero es Node.js, requiere MySQL o SQLite, y tiene su propio ecosistema de temas. Demasiada infraestructura para lo que necesito.
Escribir HTML a mano: lo consideré durante cinco minutos. Luego me acordé de que quiero escribir posts, no luchar con etiquetas <p>.
La decisión: Go sin nada
Lo que quería era simple:
- Escribir posts en Markdown con front matter YAML, como en Hugo.
- Que el servidor los lea al arrancar, los compile a HTML y los sirva desde memoria.
- Que si edito un fichero, se actualice automáticamente sin reiniciar.
- Sin base de datos. Sin frameworks frontend. Sin paso de compilación.
Go es perfecto para esto. Un binario único que arranca en milisegundos, consume poca memoria, maneja concurrencia de forma nativa y tiene una librería HTTP en la stdlib que no necesita nada externo.
La arquitectura
El servidor tiene tres componentes principales:
Loader: al arrancar, recorre content/posts/ y content/pages/, lee cada .md, parsea el front matter con adrg/frontmatter, convierte el cuerpo a HTML con goldmark y lo guarda en memoria en un Store protegido con sync.RWMutex.
Watcher: un file watcher con fsnotify que vigila el directorio de contenido. Cuando detecta un cambio, recarga solo el fichero afectado. Si creas un fichero nuevo, aparece en el blog. Si lo borras, desaparece. Sin reiniciar nada.
Server: el mux de Go 1.22+ con rutas como GET /post/{slug} y GET /{slug}. Sin router externo. Los handlers leen del Store, construyen los datos del template y renderizan con html/template.
El flujo completo de una petición es: llega la request, el handler busca el post en el Store (una lectura de mapa con RLock, nanosegundos), construye los datos del template y renderiza. No hay IO de disco ni consultas a base de datos. Todo está en memoria.
Lo que aprendí
No necesitas tanto como crees. Mi blog anterior tenía MySQL, PHP, un tema con diez ficheros, seis plugins y una configuración de Nginx de cien líneas. El nuevo tiene un binario de Go, unos templates HTML y ficheros Markdown. Hace exactamente lo mismo, más rápido, con menos superficie de ataque y con un coste de mantenimiento cercano a cero.
Goldmark es excelente. Es el parser de Markdown estándar en Go, el mismo que usa Hugo. Soporta GFM, HTML embebido y se extiende fácilmente. Con la extensión de chroma para syntax highlighting, los bloques de código se renderizan en el servidor sin enviar JavaScript al navegador.
fsnotify simplifica todo. El file watcher fue la parte que más me preocupaba y resultó ser la más sencilla. fsnotify es un wrapper sobre inotify que funciona sin sorpresas. Con un debounce de 100ms para evitar eventos duplicados y un reload selectivo por fichero, el sistema es reactivo sin ser frágil.
El mux de Go 1.22+ es suficiente. Antes necesitabas gorilla/mux o chi para tener rutas con parámetros. Ahora la stdlib soporta {slug}, verbos HTTP en el patrón y precedencia por especificidad. Para un blog no necesitas más.
El despliegue
El blog corre como un servicio de systemd en un servidor Debian detrás de Cloudflare. Nginx hace de reverse proxy y Cloudflare gestiona el SSL del edge y la cache de estáticos. El binario arranca en menos de un segundo, consume unos 20MB de RAM y sirve las páginas en microsegundos.
Para publicar un post, escribo el .md en local, lo subo por SCP o por el API, y el watcher o el endpoint de reload se encarga del resto. Sin pipelines de CI/CD, sin deploys de cinco minutos, sin Docker. Un scp y listo.
¿Lo recomiendo?
Construir tu propio blog es un ejercicio interesante pero no es para todo el mundo. Si quieres escribir y publicar sin pensar en tecnología, WordPress sigue siendo la mejor opción. Si quieres un sitio estático sin complicaciones, Hugo es fantástico.
Pero si eres desarrollador, si te gusta entender cómo funcionan las cosas por dentro y si tienes un par de fines de semana libres, construir tu propio blog es una de las mejores formas de aprender. Tocas HTTP, templates, parsing, file watching, concurrencia, despliegue y rendimiento. Todo en un proyecto real que vas a usar todos los días.
Y lo mejor de todo: cuando algo no funciona, sabes exactamente dónde mirar. Porque lo has escrito tú.