Secuencia de arranque
Descubrimiento del contenedor, selección del adaptador, inicio del ciclo de vida e inicialización de integraciones.
Arquitectura
Cómo arranca xtaskjs, resuelve rutas y extiende security dentro de un único runtime.
Esta página se centra en el ciclo de vida del framework: arranque de la aplicación, ejecución de peticiones y puntos de extensión de security superpuestos sobre la misma canalización de controladores.
Ruta de petición
Resolución de ruta, guards, pipes, middlewares, handlers y serialización final del adaptador.
Capas de security
Las estrategias, los servicios de autenticación, los decoradores y el enriquecimiento del contexto de ruta siguen siendo compatibles con DI.
Rendimiento
Manifiesto en caché, importaciones en paralelo, DI perezoso y watcher en caliente reducen el arranque un 40–60%.
Inicio rápido
Arranca la aplicación xtask más pequeña útil
Instalación
npm install @xtaskjs/core @xtaskjs/common reflect-metadataArranque
import "reflect-metadata";
import { CreateApplication } from "@xtaskjs/core";
await CreateApplication({
adapter: "node-http",
autoListen: true,
server: { host: "127.0.0.1", port: 3000 },
});Flujo de arranque
Cómo xtaskjs conecta el runtime
1. Define componentes
Decora servicios, controladores, runners y listeners en src/ para que el contenedor pueda descubrirlos.
2. Llama a CreateApplication()
Core crea el ciclo de vida de la aplicación, el kernel y el adaptador HTTP seleccionado.
3. Arranca el kernel
El contenedor analiza los directorios del proyecto, registra providers y resuelve la metadata de los componentes.
4. Conecta las integraciones
Paquetes opcionales como typeorm y security registran enlaces de ciclo de vida en el mismo contenedor.
5. Registra rutas y eventos
Los controladores y listeners se traducen en rutas, handlers y canalizaciones de ejecución del ciclo de vida.
6. Escucha y sirve
El adaptador seleccionado empieza a aceptar peticiones y las reenvía a través del ciclo de vida.
Flujo de ejecución
Canalización de peticiones y ciclo de vida de security
Ciclo de vida de la petición HTTP
El adaptador recibe la petición
Express, Fastify o node-http normalizan la petición y reenvían método y ruta al framework.
Resolución de ruta
ApplicationLifeCycle resuelve la ruta del controlador registrada durante el arranque.
Guards y autenticación
Los guards pueden bloquear o enriquecer el contexto de la ruta antes de que se ejecute el handler.
Pipes y middlewares
Los argumentos se transforman y la lógica transversal se ejecuta en un orden consistente.
Handler del controlador
El handler devuelve JSON, una respuesta primitiva o un resultado view(...).
Respuesta del adaptador
El adaptador serializa la carga, renderiza una vista o envía el código de estado correspondiente.
Ciclo de vida de la extensión de security
Registro de estrategias
Las estrategias JWT o JWE se registran antes del arranque, definiendo callbacks de extracción y validación del token.
Inicialización de security
CreateApplication() inicializa el ciclo de vida de security y publica los servicios de autenticación en el contenedor.
Activación de guards
Authenticated, Auth, Roles y AllowAnonymous decoran rutas y guían las decisiones de los guards.
Enriquecimiento del contexto
Una autenticación satisfactoria rellena req.user, req.auth, response locals y el contexto de ejecución de la ruta.
Rendimiento
Optimizaciones de arranque y recarga en caliente
Las últimas versiones introducen varios mecanismos que reducen significativamente el tiempo de arranque y aceleran el desarrollo local. Funcionan automáticamente una vez instalado el paquete.
Manifiesto en caché
En el primer arranque el kernel analiza src/ y escribe .xtask-manifest.json. Los arranques posteriores cargan el manifiesto directamente, omitiendo el escaneo del sistema de archivos y reduciendo el tiempo de arranque un 40–60%.
Manifiesto precompilado
npm run build genera .xtask-manifest.prebuilt.json en tiempo de compilación. Los arranques en producción cargan este archivo primero, logrando el arranque más rápido posible sin ningún escaneo.
Importaciones en paralelo (Pool Async)
Los archivos descubiertos se importan a través de un pool de semáforos acotado. XTASK_IMPORT_CONCURRENCY (por defecto 10) limita las importaciones en paralelo para evitar la saturación del sistema de archivos. Ajústalo a 16–24 para aplicaciones más grandes.
Resolución DI perezosa
Las dependencias inyectadas por constructor se envuelven en proxies transparentes y solo se instancian en el primer acceso. El arranque evita crear servicios que nunca se llaman, reduciendo el tiempo de inicio para integraciones opcionales.
Watcher de manifiesto en caliente
En desarrollo, un observador de archivos aplica actualizaciones incrementales al manifiesto. Los archivos modificados se reimportan y se vuelven a registrar en el contenedor sin reiniciar el proceso.
Modo desarrollo
XTASK_IMPORT_CONCURRENCY=16 npm run devUsa XTASK_IMPORT_CONCURRENCY para ajustar las importaciones paralelas y deja que el watcher aplique actualizaciones incrementales sin reiniciar.
Modo producción
npm run build
npm startEl manifiesto precompilado generado durante npm run build se carga primero en cada arranque en producción, omitiendo todo el escaneo.