Cómo operábamos krodox.com sin base de datos

Cuando se habla de escalar un sitio web, normalmente se piensa en tráfico: peticiones, servidores, balanceadores de carga. En un sitio de contenido eso rara vez es lo difícil. Lo difícil son las personas: cuántas pueden cambiar el sitio sin esperar a un desarrollador, y cuánto pueden romper al intentarlo.

Así operábamos krodox.com, nuestro antiguo sitio, sin base de datos. Cada página, cada artículo y cada documento legal era un archivo Markdown con un pequeño bloque de YAML al principio, en el mismo repositorio Git que el código.

El contenido son archivos

No había tabla posts. Un artículo era un archivo, y su título, descripción y etiquetas vivían en el front matter:

---
title: 'Cómo operábamos krodox.com sin base de datos'
tags:
    - statamic
seo:
  title: 'Cómo operábamos krodox.com sin base de datos'
  description: 'Cada página de nuestro antiguo sitio era un archivo Markdown en Git.'
---

Statamic leía esos archivos directamente, y aun así ejecutaba su panel de control con una sola cuenta de usuario, pero el contenido siempre vivió en los archivos Markdown en Git. Esa única decisión eliminaba una cantidad sorprendente de maquinaria: sin migraciones, sin seeders, sin copias de seguridad de base de datos, sin desfase de datos entre staging y producción, y sin el clásico encargo de exportar el contenido de producción solo para poder trabajar en local.

Git es el registro de auditoría

Como el contenido eran archivos, cada cambio era un commit. Quién cambió una página, cuándo, y qué decía antes la frase: eso era git log, no una tabla de revisiones que alguien tuvo que construir y mantener.

También significaba que el contenido y el código que lo renderiza se movían juntos. Un rediseño que cambiaba la forma de un artículo y los artículos mismos entraban en el mismo commit, se revisaban juntos y se revertían juntos. Necesitamos esa reversión más de una vez.

Markdown es la única habilidad necesaria

Markdown era el mínimo para contribuir. No hacía falta saber PHP, ni las interioridades de Git, ni qué es un paso de compilación. Si sabes escribir, sabes escribir Markdown, y el mismo archivo funcionaba igual editado desde un editor de texto, desde el panel de control o por un desarrollador en una rama.

Lo que cuesta

Esto no está libre de compromisos, y conviene ser honestos.

Los archivos planos dejan de ser la respuesta obvia en cuanto necesitas consultar el contenido como si fueran datos: filtrar miles de entradas por varias dimensiones, o permitir que los lectores busquen por campos estructurados. Statamic indexa contenido para búsqueda sin problema, pero si tu "contenido" es en realidad un inventario, la herramienta correcta es una base de datos.

El otro coste es que editar contenido es desplegar. Eso es una ventaja cuando quien escribe se maneja con un repositorio, y fricción cuando no.

Para un sitio cuyo trabajo era explicar a qué se dedica una empresa, el intercambio nos favorecía con claridad. No había base de datos que respaldar, ni contenido escondido en tablas, ni estado viviendo en ningún sitio que no fuera el repositorio.