Adapters de edge y serverless

Más allá de tu propio servidor Node, las grandes plataformas —Vercel, Netlify, Cloudflare— ejecutan tu código bajo demanda sin que tú administres ninguna máquina. Cada una tiene su adapter oficial, pero la diferencia más honda no está en el nombre del proveedor: está en el runtime. Las funciones serverless de Vercel y Netlify corren sobre Node, con toda su API a mano. Los runtimes de edge —los Workers de Cloudflare, el edge de Vercel, las funciones de edge de Netlify— corren sobre APIs estándar de la web, en workerd o en Deno, donde no existen fs, ni process, ni los módulos nativos de Node. Esa frontera de runtime, y no la marca comercial, decide qué puede hacer tu código y cómo debes escribirlo.

Serverless: funciones Node bajo demanda

El modelo serverless empaqueta tu código en funciones que la plataforma invoca cuando llega una petición y descarta cuando termina. No hay servidor que administrar: escala a cero cuando nadie visita y se multiplica solo bajo carga. Los adapters de Vercel y Netlify producen, por defecto, funciones sobre el runtime Node, así que dispones de casi toda su API —incluidos módulos nativos como Sharp— con las salvedades propias de un sistema de ficheros efímero y de solo lectura.

npx astro add vercel
# o
npx astro add netlify

import { defineConfig } from 'astro/config';
import vercel from '@astrojs/vercel';

export default defineConfig({
  output: 'server',
  adapter: vercel(),
});

El precio de esa comodidad es el cold start: cuando una función lleva rato dormida, la primera petición paga el arranque del entorno antes de responder. A cambio, no mantienes ni parcheas nada, y solo pagas por invocación. Estos adapters añaden además capacidades propias de la plataforma —renderizado incremental, optimización de imágenes, analíticas— que activas por opciones, sin salir de tu proyecto.

Edge: el runtime web, sin Node debajo

El edge lleva el cómputo a decenas de ubicaciones cercanas al usuario y lo ejecuta en un runtime distinto: no Node, sino un motor construido sobre los estándares de la web. Cloudflare corre en workerd; el edge de Vercel y Netlify, en variantes basadas en Deno y en Web APIs. Ahí dispones de fetch, Request, Response, URL, crypto.subtle y los Web Streams —pero no de fs, ni del process completo, ni de complementos nativos compilados—.

npx astro add cloudflare

import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  output: 'server',
  adapter: cloudflare(),
});

Un proveedor, varias palancas de runtime

Vercel y Netlify no son un único runtime monolítico: sus adapters exponen opciones que desplazan trabajo entre la función Node y el edge, para que ajustes dónde ocurre cada cosa sin cambiar de proveedor. Dos palancas concentran casi todo. edgeMiddleware mueve tu middleware de Astro al edge, donde corre antes de que la petición llegue a la función —perfecto para autenticación, redirecciones o geolocalización con latencia mínima—. Y isr, el renderizado estático incremental, cachea la salida de una ruta bajo demanda para servir la mayoría de las visitas como si fueran estáticas, recomputando solo cuando el caché expira.

import { defineConfig } from 'astro/config';
import vercel from '@astrojs/vercel';

export default defineConfig({
  output: 'server',
  adapter: vercel({
    edgeMiddleware: true,        // el middleware corre en el edge
    isr: { expiration: 60 },     // cachea la salida bajo demanda 60 s
  }),
});

Netlify expone las mismas ideas con su propia forma, prueba de que estas palancas son un patrón del ecosistema y no un truco de un solo proveedor:

import { defineConfig } from 'astro/config';
import netlify from '@astrojs/netlify';

export default defineConfig({
  output: 'server',
  adapter: netlify({ edgeMiddleware: true }),
});

Un mismo motor, muchos destinos

Lo asombroso de esta variedad es que tu proyecto no cambia al elegir uno u otro. La misma página que se renderiza en tu Node local se renderiza en una función serverless de Vercel o en un Worker de Cloudflare, porque en los tres casos el motor recibe un Request y devuelve un Response. El adapter absorbe todo lo que difiere entre destinos; tu código habla el idioma común.

flowchart TD
APP[motor de Astro sobre Request y Response] --> NODE[adapter node]
APP --> VER[adapter vercel]
APP --> NET[adapter netlify]
APP --> CF[adapter cloudflare]
NODE --> SRV[servidor node propio]
VER --> FN[funciones serverless o edge]
NET --> FN2[funciones o edge de netlify]
CF --> WK[workers en el edge]
style APP fill:#89b4fa,color:#11111b
style WK fill:#a6e3a1,color:#11111b