Hasta este punto del curso, hemos estado trabajando en modo SSG (Static Site Generation).
En este modo, cuando ejecutamos npm run build, Astro genera una carpeta dist/ llena de archivos HTML. Si tienes un blog, eso es perfecto. Subes esos archivos a cualquier servidor y listo.
Pero, ¿qué pasa si necesitamos saber quién es el usuario que visita la web? ¿O si queremos mostrar el precio de Bitcoin en tiempo real? ¿O leer cookies de sesión?
Un archivo HTML estático no puede hacer eso. Necesitamos que el servidor “piense” y genere la página en el momento en que el usuario la solicita.
Esto es el Server Side Rendering (SSR).
Los modos de salida (output)
Astro tiene tres modos de funcionamiento que definimos en astro.config.mjs bajo la propiedad output.
output: 'static' (Por defecto)
Es lo que hemos usado hasta ahora.
- Cuándo se construye: En tiempo de compilación (Build time).
- Velocidad: Máxima (es solo servir archivos).
- Coste: Mínimo.
- Uso: Blogs, portfolios, landings, documentación.
output: 'server' (SSR Puro)
Convierte tu proyecto en una aplicación de servidor. Cada vez que alguien entra a tu web, el servidor ejecuta el código, consulta la base de datos y genera el HTML.
- Cuándo se construye: En cada petición (Request time).
- Velocidad: Depende de tu código y base de datos.
- Capacidades: Acceso a Cookies, Headers, APIs privadas, contenido dinámico.
- Uso: SaaS, redes sociales, e-commerce dinámico.
output: 'hybrid' (El punto dulce)
Esta es una característica genial de Astro. Mantiene el comportamiento Estático por defecto, pero te permite marcar ciertas páginas como dinámicas.
- Uso: Tienes un blog (estático) pero quieres una página de
/loginy un/perfil(dinámicos).
Resumen: ¿Qué elijo?
| Necesidad | Modo (output) | Adaptador |
|---|---|---|
| Blog personal, documentación, portfolio | static | Ninguno (o el del hosting para features extra) |
| Web corporativa con formulario de contacto | hybrid | Node / Vercel / Netlify |
| Dashboard, SaaS, Red Social | server | Node / Vercel / Netlify |
| Tienda Online | server o hybrid | Node / Vercel / Netlify |
Activando el modo SSR
Para cambiar de modo, editamos nuestro archivo de configuración:
// astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
output: 'server', // O 'hybrid'
});
Si guardas esto e intentas hacer un build, Astro te lanzará un aviso. Falta una pieza clave: El Adaptador.
Cuando generas HTML estático, no importa dónde lo alojes. HTML es estándar.
Pero cuando usas SSR, estás ejecutando código JavaScript en el servidor. Y no todos los servidores son iguales.
- Node.js espera un servidor HTTP clásico.
- Vercel usa “Serverless Functions” con una sintaxis específica.
- Cloudflare usa “Workers” en el borde (Edge) con un runtime que no es Node.
Astro no sabe dónde vas a desplegar tu web. Por eso, necesitas instalar un Adaptador que haga de traductor entre Astro y tu proveedor de hosting.
Instalando un Adaptador
Al igual que con React o Tailwind, usamos el comando astro add.
Para servidores VPS o locales (Node.js)
Si vas a alojar tu web en un servidor propio, en un contenedor Docker, o en un servicio como DigitalOcean o Railway.
npx astro add node
Para la nube (Vercel / Netlify)
Si usas plataformas de despliegue automático (“Serverless”).
npx astro add vercel
# o
npx astro add netlify
Astro configurará automáticamente el adaptador en tu astro.config.mjs:
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';
export default defineConfig({
output: 'server',
adapter: node({
mode: 'standalone', // Crea un servidor independiente
}),
});
Cambios en el código: El objeto Astro.request
Una vez activado el SSR, ganamos acceso a nuevas capacidades en el frontmatter de nuestros componentes.
Ahora podemos leer las cabeceras de la petición o las cookies:
---
// src/pages/perfil.astro
// Solo en modo SSR podemos acceder a las cookies
const usuarioCookie = Astro.cookies.get('user_session');
if (!usuarioCookie) {
// Podemos redirigir desde el servidor
return Astro.redirect('/login');
}
const usuario = await buscarEnBaseDeDatos(usuarioCookie.value);
---
<h1>Hola de nuevo, {usuario.nombre}</h1>
¡Adiós a getStaticPaths!
En una página puramente SSR (output: 'server'), ya no exportamos getStaticPaths para las rutas dinámicas ([id].astro).
Como la página se genera en el momento, Astro lee el ID directamente de la URL (Astro.params.id) y tú te encargas de buscar los datos en ese instante.
El paso al SSR es emocionante porque es donde la web se vuelve “inteligente”. Ahora que tenemos un servidor, podemos empezar a construir APIs.
Sí, has leído bien. En el próximo artículo veremos cómo usar Astro para crear tus propios Endpoints de API que devuelvan JSON en lugar de HTML.
