Para un portfolio de desarrollador, la capa de contenido debe cumplir dos objetivos: fácil de editar para el desarrollador, y fácil de extender cuando los requisitos crecen. Un CMS alojado es genial para equipos; para un desarrollador en solitario que escribe artículos técnicos ocasionales, es excesivo — otra cuenta, otra API, otra cosa que se puede caer.
El montaje
Cada artículo es un archivo Markdown con frontmatter YAML, uno por idioma, dentro del repo en content/blog/:
content/blog/
mi-articulo.en.mdx
mi-articulo.es.mdx
El frontmatter lleva los metadatos — título, resumen, fecha, tags — y el cuerpo es Markdown normal. Un pequeño script de build lee el frontmatter de cada archivo y escribe un índice de metadatos que consumen la lista de artículos, el sitemap y las tarjetas de proyectos. Los cuerpos de los artículos se leen directamente del disco en tiempo de compilación y se renderizan como páginas estáticas.
Por qué MDX y no Markdown a secas
El noventa por ciento de un artículo es prosa, títulos, bloques de código y alguna imagen — todo Markdown estándar. Pero de vez en cuando un tema necesita un diagrama con el que puedas interactuar de verdad: una gráfica que responde a un slider, una pequeña demostración que puedes recorrer paso a paso. MDX me deja meter un componente React en medio de la prosa para exactamente esos momentos, sin convertir todo el pipeline en una app.
El Markdown estándar cubre el 90%.
Un componente React cubre el 10% que necesita moverse.
Cuándo tiene sentido un CMS
- Varios autores no técnicos que no van a tocar Git
- Un flujo de publicación con borradores, programación y revisión
- Contenido reutilizado en varias superficies (web, email, móvil)
Nada de eso aplica a una persona escribiendo un puñado de posts al año.
Empieza con la capa de contenido más simple que resuelva el problema. Siempre puedes migrar a un CMS cuando la escritura supere a una carpeta de archivos.