Arquitectura

Una visión práctica de lo que se ejecuta en tus máquinas cuando despliegas ObjectOS, qué datos salen de tu red y cuáles no.

El modelo mental son dos capas delgadas:

1. Metadatos — paquetes de objetos / vistas / acciones / flujos / agentes. En su mayoría escritos por el AI Builder contra una API de herramientas en un entorno aislado (sandbox); a veces editados a mano, siempre con control de versiones y auditados.
2. Un único runtime de Node.js que interpreta esos metadatos en una aplicación funcional — REST API, Console UI, permisos, trabajos, herramientas de IA — todo en un solo proceso, comunicándose con tu base de datos.

Sin paso de generación de código, sin pipeline de despliegue entre "el usuario describió lo que quería" y "está en producción". El runtime carga en caliente los nuevos metadatos tras una aprobación HITL.

Lo que despliegas

Un proceso de Node.js por instancia de ObjectOS. Eso es todo.

┌─────────────────────────────────────────────────────┐
│                  ObjectOS process                   │
│  ┌───────────────────────────────────────────────┐  │
│  │   HTTP dispatcher  (/ · /api · /_console …)    │  │
│  ├───────────────────────────────────────────────┤  │
│  │   Per-project ObjectKernel (LRU cached)       │  │
│  │   ├─ Auth (Better Auth)                       │  │
│  │   ├─ Security (RBAC + row-level + field)      │  │
│  │   ├─ ObjectQL (data engine, generates SQL)    │  │
│  │   ├─ REST API generator                       │  │
│  │   └─ Capabilities loaded per artifact         │  │
│  │      (audit, storage, jobs, queue, AI …)      │  │
│  └───────────────────────────────────────────────┘  │
└──────────┬──────────────────────────────────────────┘
           │
           ▼
   Your business database
   (Postgres / MySQL / SQLite / Turso / MongoDB)

Equivale a la complejidad de un único binario enlazado estáticamente. Sin sidecar, sin Kafka, sin necesidad de una capa de caché separada. Añade esas cosas cuando las necesites; no pagues por ellas desde el primer día.

Dónde viven tus datos

ObjectOS no se comunica con el exterior. Sin telemetría. Sin verificación de licencia. Si cortas el acceso a internet por completo, sigue funcionando indefinidamente. Consulta Air-gapped.

Cómo se atiende una solicitud

1. Ingress / TLS termination     (your load balancer)
2. HTTP dispatcher               (security headers, request id)
3. Hostname → project resolution (cached, TTL configurable)
4. Get or build per-project kernel from LRU
5. AuthPlugin    — session cookie, bearer token, or API key
6. SecurityPlugin — RBAC + row-level + field-level checks
7. Route handler — generated REST, declarative action, or custom
8. Data driver   — ObjectQL compiles to SQL / Mongo query
9. Response with X-Request-Id propagated

Los pasos 4-8 normalmente se ejecutan en < 5ms una vez que el kernel está caliente.

Las tres capas (solo importa si estás integrando)

La mayoría de los clientes despliegan únicamente ObjectOS. Las otras dos capas existen por si quieres saber de dónde viene el artefacto:

Si estás distribuyendo una sola app, no necesitas un plano de control — compila objectstack.config.ts → dist/objectstack.json en tu CI y distribuye el JSON en la imagen. Si estás ejecutando un marketplace interno de apps con muchos inquilinos y aplicaciones, el plano de control es donde reside el catálogo.

Modos de arranque

El modo se detecta automáticamente a partir de las variables de entorno.

Características de rendimiento

Por qué esta forma

• Un proceso de Node, sin sidecars → cabe en un docker run, cabe en una unidad systemd, cabe en un entorno tipo Lambda.
• Kernel por proyecto, con caché LRU → una instancia puede atender muchas apps pequeñas sin pagar el coste de calentamiento en cada solicitud.
• APIs generadas sobre metadatos declarados → no hay paso de codegen en tu CI, ni SDK de cliente que publicar; la API coincide con tu modelo de datos por construcción.
• Todas las capacidades son plugins opcionales → el tamaño de la imagen escala con lo que realmente usas.

A dónde ir después

• Production Readiness — checklist antes de exponerlo a tráfico real.
• Runtime Configuration — conexión de bases de datos, cachés y secretos.
• Runtime Capabilities — qué paquetes opcionales existen y qué habilitan.