Skip to content

Enrutamiento estilo Next.js: beneficios practicos en FastFN

Estado verificado al 28 de marzo de 2026. Nota de runtime: FastFN auto-instala dependencias locales de funcion desde requirements.txt / package.json; los runtimes del host son necesarios en fastfn dev --native, mientras que fastfn dev depende de un daemon Docker corriendo. Este documento resume por que FastFN adopto enrutamiento estilo Next.js (tecnico: file-based routing con convenciones de segmentos dinamicos) como DX por defecto y que se valido en ejecuciones reales.

1. Loop de desarrollo mas rapido

  • No se necesita fn.config.json por endpoint.
  • El runtime se infiere de la extension (.js, .py, .php, .rs, .go).
  • Archivos y carpetas nuevos se detectan en dev sin reiniciar (fastfn dev monta el root completo).

Resultado:

  • Menos pasos manuales de config.
  • Menos drift entre codigo y config de ruteo.

2. Mapeo de URLs claro y predecible

El nombre del archivo mapea directamente a la ruta:

  • users/index.js -> GET /users
  • users/[id].js -> GET /users/:id
  • blog/[...slug].py -> GET /blog/:slug*
  • post.users.[id].py -> POST /users/:id

Esto elimina reglas de ruteo ocultas y hace las rutas descubribles leyendo el arbol.

3. Overrides seguros en vez de "todo o nada"

La precedencia es deterministica:

  1. fn.config.json
  2. fn.routes.json
  3. rutas basadas en archivos

Comportamiento importante:

  • Un fn.config.json vacio o invalido no rompe el discovery.
  • fn.routes.json solo sobreescribe pares ruta+metodo que coincidan.
  • Las rutas de archivo que no se solapan siguen activas.

Esto mantiene control explicito donde se necesita y preserva la conveniencia zero-config.

4. Soporte monorepo multi-app

fastfn dev <root> soporta multiples apps/directorios en una corrida.

Ejemplos validados:

  • GET /nextstyle-clean/users -> 200
  • GET /nextstyle-clean/blog/a/b -> 200
  • POST /nextstyle-clean/admin/users/123 -> 200
  • GET /items -> 200 (desde polyglot-demo/fn.routes.json)
  • POST /items -> 200
  • GET /items/123 -> 200
  • DELETE /items/123 -> 200

Esto habilita un stack local para demos/servicios mixtos.

5. Mejor historia poliglota

En un solo root, rutas Node/Python/PHP/Rust pueden coexistir naturalmente.

Validado con:

  • Playwright E2E: 6 passed
  • Script de integracion (tests/integration/test-multilang-e2e.js): todos los checks pasaron
  • Tests CLI: pasaron
  • Cobertura de discovery: 89.6%

6. Visibilidad operativa (Warm/Cold)

El gateway ahora senaliza el estado del runtime:

  • X-FastFN-Function-State: cold|warm
  • X-FastFN-Warmed: true en exito de cold-start
  • X-FastFN-Warming: true + Retry-After: 1 mientras se calienta

Para handlers Rust compilados, el tiempo de build del primer hit es acotado y configurable:

  • FN_RUST_BUILD_TIMEOUT_S (default 20)

Esto reduce ambiguedad durante cold starts y ayuda al debugging.

7. La superficie interna se puede deshabilitar limpiamente

Comportamiento validado con:

  • FN_DOCS_ENABLED=0
  • FN_ADMIN_API_ENABLED=0

Resultados:

  • GET /_fn/docs -> 404
  • GET /_fn/openapi.json -> 404
  • GET /_fn/catalog -> 404
  • Rutas de usuario (por ejemplo GET /docs/a/b) siguen funcionando (200)

Asi el tooling interno puede estar apagado en ambientes hardened sin sacrificar rutas de la app.

8. Por que esto mejora la DX

  • Menor friccion de setup.
  • Mejor fuente de verdad: la ruta esta cerca del codigo del handler.
  • Onboarding mas facil para equipos que ya usan convenciones de file-based routing.
  • Mas escalable para monorepos y lenguajes mixtos.
  • Camino de migracion mas limpio: config explicita y manifests siguen funcionando donde se necesite.

Problema

Que dolor operativo o de desarrollo resuelve este tema.

Modelo mental

Como razonar sobre esta funcionalidad en ambientes tipo produccion.

Decisiones de diseno

  • Por que existe este comportamiento
  • Tradeoffs aceptados
  • Cuando elegir alternativas

Ver tambien

Última revisión: 28 de marzo de 2026 · Docs en fastfn.dev