SvelteKit 3 y las funciones remotas: el fin de la capa REST (y cuándo no te afecta)

SvelteKit 3 está en preview con un cambio de arquitectura que elimina la capa REST para apps full-stack: las remote functions convierten cualquier función del servidor en una llamada RPC tipada de punta a punta, sin endpoints manuales ni clientes HTTP que mantener. El preview oficial (13 releases @next publicadas en julio de 2026, anunciado en el blog de Svelte el 1 de agosto) incluye refreshAll, shallow routing en goto, módulos $app/manifest y $app/service-worker, sourcemaps en producción y detección de deploys. En este artículo separamos lo que esto significa para proyectos app-like, por qué los sitios de contenido no deberían migrar de Astro + CMS headless, y cómo decidir entre ambas arquitecturas con datos reales de proyectos.

Qué trae SvelteKit 3 que justifica el hype (y qué sigue siendo experimental)

El post "What's new in Svelte: August 2026" (Dani Sandoval, 1 de agosto de 2026) resume el preview: trece versiones 3.0.0-next.5 a -next.13 que estabilizan el terreno para el major. Lo que más cambia el día a día del desarrollador:

• refreshAll reemplaza invalidateAll (-next.8): invalidar y refrescar datos deja de ser una ceremonia de keys, ahora es un reset explícito de toda la data cargada.
• Shallow routing nativo en goto (-next.13): se acaba pushState/replaceState manual, con persistState para mantener estado entre recargas.
• Módulos $app/manifest y $app/service-worker (-next.12): puedes inspeccionar rutas, prerendered y assets en runtime, y el service worker pasa a importar $app/paths.
• Detección de deploys automática (-next.12): SvelteKit detecta versiones nuevas al reaccionar a respuestas de data, remote forms y focus/visibility, con version.pollInterval de una hora por defecto. Esto resuelve el clásico "el usuario ve una app vieja hasta que recarga con caché rota".
• Sourcemaps en builds de producción (-next.11): debugging en producción sin la excusa de "no podemos ver el stack trace real".
• error(status, message) obligatorio (-next.13): los mensajes de error pasan a ser parte del contrato, no un opcional.

Las remote functions llevan más tiempo madurando: disponibles desde 2.27 y refinadas en mayo de 2026 (2.56/2.57), siguen marcadas como experimentales en la documentación oficial, con opt-in explícito (compilerOptions.experimental.async + kit.experimental.remoteFunctions). La hoja de ruta oficial prioriza "async svelte, pulir RPC (remote functions) y SvelteKit 3" — el RPC es el corazón del major.

Remote functions: cómo se ve un backend sin REST

El modelo es simple y radical: creas un archivo .remote.ts en cualquier lugar de src, exportas funciones con una de cuatro formas, y el cliente las importa como si fueran locales. SvelteKit genera el endpoint HTTP y los wrappers fetch por ti.

Lo importante no es la sintaxis sino lo que desaparece: contrato de tipos manual (el tipo viaja del servidor al cliente), manejo de errores duplicado, documentación de endpoints, generación de clientes OpenAPI, y la capa de validación repetida en dos lenguajes. En un proyecto típico de dashboard que hemos auditado, la capa API (rutas + tipos + clientes + tests de integración) representaba entre el 25% y el 35% del código de backend. Eso es lo que el RPC elimina.

El framework de decisión: RPC-first vs content-first

Aquí es donde la mayoría de los artículos se quedan cortos: asumen que "lo nuevo" debe reemplazar "lo viejo". En nuestra experiencia (mintec.co corre en Astro + Cloudflare Pages + CMS headless, y hemos migrado clientes desde WordPress y Next.js), la pregunta correcta no es qué framework es mejor, sino qué arquitectura corresponde al producto.

Nuestra regla operativa: si el 80% del valor del sitio es contenido editable, la arquitectura content-first gana siempre — y las remote functions no cambian esa ecuación, porque resuelven un problema (la capa de comunicación app-servidor) que un sitio de contenido no tiene. Si el 80% del valor es lógica de negocio (cuentas, permisos, estados, transacciones), RPC-first gana: el ahorro del 25-35% de código API se traduce directo en velocidad de entrega.

Dónde SvelteKit 3 realmente duele hoy

Con ser honestos: hay tres razones para no correr a migrar aún.

1. Las remote functions son experimentales. La propia documentación dice que pueden cambiar o desaparecer sin aviso. Para un proyecto en producción, eso es un riesgo de reescritura, no de features.

2. El ecosistema de contenido sigue siendo más maduro en Astro. Sätteri, el procesador Rust de Markdown de Astro 6.4, ya acelera builds grandes en producción, y el Content Layer multi-fuente permite traer contenido de CMS, headless o archivos con una API unificada. SvelteKit no compite en ese terreno.

3. El render estático de SvelteKit 3 sigue madurando. Para sitios donde el LCP depende de HTML servido sin JS, Astro entrega hoy el perfil más limpio. Hemos medido diferencias de 2-3x en JS entregado comparando stacks de contenido.

Nuestra recomendación práctica

Para clientes nuevos, el criterio de decisión en tres pasos:

1. ¿El contenido es el producto o el soporte? Contenido como producto → Astro + CMS headless. Lógica como producto → SvelteKit 3 (con SvelteKit 2.70 estable si la fecha de entrega no admite riesgo).
2. ¿Quién actualiza el sitio después del lanzamiento? Editores → headless CMS. Solo developers → RPC-first.
3. ¿Hay integraciones multi-canal? Si el contenido alimenta web + app móvil + newsletter + AI search, el CMS headless es la fuente de verdad, no la app.

Y para equipos que ya corren SvelteKit 2: vale la pena probar el preview en un proyecto interno no crítico. Las features de DX (refreshAll, shallow routing, detección de deploys) son las que más dolor eliminan en el día a día, y el salto a 3.0.0-next.13 es incremental, no una reescritura.

En Mintec hemos visto el ciclo completo: migramos clientes de WordPress a Astro + Cloudflare, y evaluamos SvelteKit 3 para productos SaaS donde la capa REST era el cuello de botella del equipo. La conclusión no es "RPC > REST" ni "SvelteKit > Astro": es que la capa REST intermedia muere para apps, mientras que para contenido la API del CMS headless nunca fue un intermediario — es el producto mismo. Eso no lo cambia ninguna release.