Adapters de edge y serverless

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# onpx 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.