🚀 Nuevo modo Snapshot en Content Island

Cuando trabajas con Astro en modo SSG, las consultas a Content Island (Headless CMS) se resuelven durante el build.

Se genera el HTML, se despliega y a partir de ahí todo se sirve de forma estática. Sin llamadas a APIs. Sin dependencias externas. Máxima velocidad.

Pero cuando entramos en SSR o ISR (Astro, Next.js, TanStack Start, Nuxt o cualquier framework moderno), la historia cambia.

Ahora sí hay consultas a Content Island durante la ejecución de la aplicación.

¿Es rápido? Sí.

¿Podemos añadirle caché? También.

Pero había una pregunta que me rondaba la cabeza:

👉 ¿Y si pudiéramos tener la flexibilidad del SSR y, al mismo tiempo, la velocidad de una aplicación estática?

De ahí nace el nuevo modo Snapshot.

¿Qué hace exactamente?

La idea es muy simple.

Primero exportas un snapshot de tu proyecto Content Island a un fichero JSON:

npx content-island export --access-token <your-read-token>

Acuerdate que para poder ejecutar este comando, previamente necesitas tener instalado el paquete de api cliente de content island npm i @content-island/api-client, o ejecutar directamente npx @content-island/api-client export --access-token <your-read-token>

Ese snapshot contiene toda la estructura y contenido textual de tu proyecto. Los recursos multimedia siguen sirviéndose desde CDN como siempre.

Después, donde creas tu cliente de Content Island, activas el modo snapshot:

export const contentIslandClient = createClient({
  accessToken: ENV.CONTENT_ISLAND_TOKEN,
+  mode: 'snapshot',
});

Y ya está.

Literalmente.

A partir de ese momento el snapshot se carga en memoria y todas las consultas se resuelven desde ahí, sin realizar llamadas a la API de Content Island.

La mejor petición HTTP siempre será la que no necesitas hacer. 😎

¿Cómo de complicado es activarlo?

Una línea.

Si ya tienes una aplicación funcionando con Content Island, el cambio suele reducirse a indicar el modo y la ruta del snapshot.

Vale... ¿y cómo me llevo esto a producción?

Lo habitual es generar el snapshot durante tu pipeline de despliegue.

- name: Export Content Island snapshot
  run: npx content-island export --access-token ${{ secrets.CONTENT_ISLAND_TOKEN }}

- name: Build
  run: npm run build
  
- name: Deploy
  run: npm run deploy

Incluso puedes controlar el modo mediante variables de entorno para decidir en cada entorno si trabajas contra API o Snapshot.

¿Y qué pasa cuando publico contenido nuevo?

También está cubierto.

Content Island dispone de webhooks que pueden disparar automáticamente tu pipeline de CI/CD.

El flujo sería algo así:

📝 Publicas contenido
⚡ Se dispara un webhook
📦 Se genera un nuevo snapshot
🚀 Se despliega automáticamente

Y listo.

¿Puedo mezclar API y Snapshot?

Sí.

De hecho es una de las cosas más interesantes.

Puedes mantener tu aplicación funcionando normalmente contra la API y decidir consulta a consulta qué quieres resolver desde snapshot y qué quieres resolver en tiempo real.

Por ejemplo, a nivel de consulta puedes hacer override:

await contentIslandClient.getContentList({
  id: { in: contentIslandIds },
  mode: 'snapshot',
});

O justo al contrario:

await contentIslandClient.getContentList({
  id: { in: contentIslandIds },
  mode: 'api',
});

¿Y cómo edito los contenidos?

Exactamente igual que siempre.

Puedes seguir utilizando Content Island desde la interfaz visual para que usuarios no técnicos gestionen el contenido.

O si prefieres automatizar procesos, utilizar el MCP de Content Island junto con un token de escritura.

Cuando tengas los cambios listos, simplemente generas un nuevo snapshot y vuelves a desplegar.

¿Y si quiero probar cambios antes de publicarlos?

También puedes.

Trabajando en modo PREVIEW podrás incluir contenido en borrador (draft) dentro del snapshot para validar cambios antes de publicarlos.

¿Para quién está pensado?

Principalmente para aplicaciones SSR donde:

✅ El contenido cambia poco respecto al tráfico recibido.
✅ Quieres reducir dependencias externas.
✅ Buscas exprimir al máximo el rendimiento.
✅ Te gusta la idea de que tu aplicación siga funcionando incluso aunque la API de contenidos no esté disponible temporalmente.

En resumen:

👉 Mantienes la experiencia de edición de un Headless CMS.

👉 Conservas la flexibilidad de SSR.

👉 Pero las consultas se resuelven localmente desde memoria.

Y eso se nota.

🎥 Próximamente publicaré un vídeo mostrando cómo funciona internamente, casos de uso reales y algunas métricas de rendimiento.