Por qué separé el contenido del frontend
Este mismo blog, caprini.dev, funciona con Ghost como backend de contenido y un frontend construido en Next.js que consume ese contenido a través de la Content API. No uso el tema por defecto de Ghost ni su renderizado integrado; Ghost aquí es, básicamente, un editor y una base de datos de artículos con una API bien documentada, y todo el diseño, el enrutado y el rendimiento dependen del frontend que he construido yo.
Elegí este enfoque, conocido como headless, en lugar de usar Ghost de forma tradicional, porque quería control total sobre el frontend sin renunciar a un editor de contenido cómodo para escribir. Esa combinación tiene ventajas reales, pero también complicaciones que no siempre se mencionan cuando alguien recomienda esta arquitectura.
Las ventajas que sí se cumplen
Después de meses usando esta configuración, las ventajas que más valoro son:
- El editor de Ghost es notablemente mejor para escribir que la mayoría de headless CMS genéricos que probé antes, con soporte nativo para imágenes, tarjetas de código y estructura de artículo sin plugins adicionales.
- La Content API es estable y bien documentada, lo que hace que construir la capa de consumo desde Next.js sea relativamente directo: obtener posts, tags y metadatos sigue un patrón consistente.
- Puedo desplegar el frontend de forma completamente independiente del backend de contenido, lo que significa que un cambio de diseño no implica tocar nada en Ghost, y viceversa.
- El rendimiento del sitio público depende del frontend que yo controlo, no del tema de Ghost, así que puedo optimizar exactamente lo que me importa (tiempo de carga, generación estática, imágenes) sin las limitaciones de un theme ajeno.
Los problemas que no esperaba
Aquí está la parte que menos se cuenta cuando se habla de arquitecturas headless, y que he vivido de primera mano:
Desincronización entre lo publicado en Ghost y lo que muestra el frontend. He detectado casos concretos en mi propio blog donde un artículo publicado en Ghost, y presente en el sitemap generado automáticamente, no aparecía listado en la página de índice de artículos. La causa más probable es un filtro o una condición de construcción en el frontend Next.js que no está capturando todos los posts en determinadas circunstancias (por ejemplo, según el tag asociado o el momento de la última regeneración). Esto es exactamente el tipo de problema silencioso que una arquitectura acoplada (Ghost con su propio theme) no tendría, porque el listado y el contenido vendrían de la misma fuente sin capa intermedia.
Revalidación y contenido desactualizado. Al usar generación estática o incremental en Next.js, hay que decidir con cuidado cuándo se regenera cada página tras editar un artículo en Ghost. Si la estrategia de revalidación no está bien calibrada, es fácil que una corrección publicada en Ghost tarde en reflejarse en el sitio público, lo que puede generar confusión si se está corrigiendo algo con urgencia.
Metadatos duplicados que hay que gestionar en dos sitios. Título SEO, descripción y datos estructurados a veces se definen tanto en Ghost (en los ajustes de cada post) como en el propio código del frontend. Si no se define con claridad cuál es la fuente de verdad para cada campo, es fácil que ambos se desincronicen.
Cómo estoy mitigando estos problemas
No tengo todos estos problemas resueltos del todo, pero la estrategia que estoy siguiendo es:
- Tratar el sitemap generado a partir de la Content API como la fuente de verdad de qué está realmente publicado, más que el listado visual del índice de artículos, precisamente porque he visto discrepancias entre ambos.
- Revisar periódicamente, de forma manual, que cada post nuevo aparezca tanto en el índice como en el sitemap, en lugar de asumir que la sincronización siempre funciona.
- Documentar claramente, en el propio código del frontend, qué campos de metadatos vienen de Ghost y cuáles se calculan o se sobrescriben en Next.js, para no duplicar lógica sin darme cuenta.
¿Volvería a elegir esta arquitectura?
Sí, con matices. La combinación Ghost más Next.js me da el control de frontend que quería sin renunciar a un editor cómodo, y para un blog técnico personal ese control merece la pena. Pero si alguien me pregunta si esta arquitectura es "más simple" que un Ghost tradicional con su propio theme, la respuesta honesta es que no: es más flexible, pero también añade una capa de sincronización que hay que vigilar activamente, no solo configurar una vez y olvidarse.
A quién le recomendaría esta arquitectura y a quién no
Recomendaría este enfoque a quien ya tiene claro que quiere construir su propio frontend, con su propio sistema de componentes y sus propias decisiones de rendimiento, y que valora tener un editor de contenido cómodo sin tener que construirlo desde cero. No la recomendaría a quien simplemente quiere un blog funcionando cuanto antes sin tocar código de frontend; en ese caso, un Ghost con un theme ya hecho, o incluso otra plataforma más cerrada, va a dar menos dolores de cabeza con un resultado perfectamente válido.
La diferencia, en el fondo, no es de calidad entre una opción y otra, sino de qué tipo de mantenimiento estás dispuesto a asumir a cambio de qué tipo de control.
Documentación oficial: Ghost Content API y Next.js Documentation.
Conclusión
Elegir una arquitectura headless no elimina la complejidad de gestionar contenido; la traslada de un sitio (el theme integrado) a otro (la capa de sincronización entre backend y frontend). Para mí ha merecido la pena por el control que gano sobre el frontend, pero solo porque acepto que ese control viene acompañado de revisiones manuales que un Ghost tradicional no me exigiría.