Architecture

Une vision pratique de ce qui s'exécute sur vos machines lorsque vous déployez ObjectOS, des données qui quittent votre réseau et de celles qui n'en sortent pas.

Le modèle mental repose sur deux couches légères :

1. Métadonnées — des packages d'objets / vues / actions / flows / agents. Écrits pour l'essentiel par l'AI Builder via une API d'outils en bac à sable ; parfois édités à la main, toujours versionnés et audités.
2. Un unique runtime Node.js qui interprète ces métadonnées pour en faire une application fonctionnelle — API REST, interface Console, permissions, jobs, outils d'IA — le tout dans un seul processus, communiquant avec votre base de données.

Aucune étape de génération de code, aucun pipeline de déploiement entre « l'utilisateur a décrit ce qu'il voulait » et « c'est en ligne ». Le runtime charge à chaud les nouvelles métadonnées après une approbation HITL.

Ce que vous déployez

Un seul processus Node.js par instance ObjectOS. C'est tout.

┌─────────────────────────────────────────────────────┐
│                  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)

Cela représente la complexité d'un unique binaire lié statiquement. Aucun sidecar, aucun Kafka, aucune couche de cache distincte requise. Ajoutez-les quand vous en avez besoin ; ne les payez pas dès le premier jour.

Où résident vos données

ObjectOS ne « rappelle pas la maison ». Aucune télémétrie. Aucune vérification de licence. Si vous coupez totalement l'accès à Internet, il continue de fonctionner indéfiniment. Voir Air-gapped.

Comment une requête est traitée

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

Les étapes 4 à 8 s'exécutent généralement en moins de 5 ms une fois le kernel à chaud.

Les trois couches (utile uniquement si vous intégrez)

La plupart des clients ne déploient que ObjectOS. Les deux autres couches existent si vous voulez savoir d'où provient l'artefact :

Si vous livrez une application unique, vous n'avez pas besoin d'un control plane — compilez objectstack.config.ts → dist/objectstack.json dans votre CI et livrez le JSON dans l'image. Si vous exploitez un marketplace d'applications internes avec de nombreux tenants et applications, le control plane est l'endroit où réside le catalogue.

Modes de démarrage

Le mode est détecté automatiquement à partir des variables d'environnement.

Caractéristiques de performance

Pourquoi cette forme

• Un seul processus Node, sans sidecars → tient dans un docker run, tient dans une unité systemd, tient dans un environnement de type Lambda.
• Kernel par projet, mis en cache LRU → une instance peut servir de nombreuses petites applications sans payer le coût de préchauffage à chaque requête.
• APIs générées au-dessus de métadonnées déclarées → il n'y a pas d'étape de codegen dans votre CI, pas de SDK client à publier ; l'API correspond à votre modèle de données par construction.
• Toutes les capabilities sont des plugins optionnels → la taille de l'image évolue selon ce que vous utilisez réellement.

Pour aller plus loin

• Production Readiness — checklist avant d'exposer le tout à du trafic réel.
• Runtime Configuration — câblage des bases de données, des caches et des secrets.
• Runtime Capabilities — quels packages optionnels existent et ce qu'ils activent.