Architecture

Understanding the ObjectStack Trinity. How ObjectQL, ObjectOS, and ObjectUI collaborate to build the Enterprise Kernel.

ObjectStack is not a monolithic framework. It is a composable ecosystem designed around a Layered Architecture. We call this the "ObjectStack Trinity."

Each layer is decoupled and communicates via standard JSON protocols. This allows you to swap out implementations (e.g., swapping the React renderer for a Flutter renderer) without breaking the rest of the stack.

The Trinity

1. The Data Layer: ObjectQL

"The Universal Protocol"

At the foundation lies ObjectQL. It is responsible for Data Definition and Data Access.

• Role: Defines Structure (Schema) and Intent (Query AST).
• Responsibility: It knows what a "Customer" object looks like, but it doesn't know who is accessing it or how it is displayed.
• Key Component: The Compiler. It takes an abstract query (find customers where active = true) and translates it into optimized SQL for the specific underlying database (Postgres, SQLite, MySQL).

2. The Control Layer: ObjectOS

"The Business Kernel"

Sitting in the middle is ObjectOS. It is responsible for Orchestration and Governance.

• Role: Manages the Lifecycle of a request.
• Responsibility:
  • Identity: "Who is this user?" (Authentication).
  • Security: "Can they see this field?" (RBAC/ACL).
  • Sync: "How do we merge these offline changes?" (Conflict Resolution).
  • Process: "What happens after this record is saved?" (Workflows/Triggers).
• Key Concept: It acts as the gateway. No direct database access is allowed; everything must pass through the OS Kernel.

3. The View Layer: ObjectUI

"The Projection Engine"

At the top is ObjectUI. It is responsible for Interaction and Rendering.

• Role: Consumes the Protocol to render the Interface.
• Responsibility: It does not contain hardcoded forms. Instead, it asks ObjectQL: "What is the schema for a Customer?" and dynamically renders a layout based on that metadata.
• Key Concept: Server-Driven UI (SDUI). The backend dictates the layout, validation rules, and available actions. The frontend is merely a highly capable renderer.

---

The Request Lifecycle

To understand how these pieces fit together, let's trace a typical user interaction—for example, a Sales Rep updating a deal status while offline.

1. Interaction (ObjectUI):

   • User drags "Deal" to "Closed Won" column in Kanban.
   • UI Optimistically updates the screen (0ms).
   • UI dispatches an update action to the local ObjectOS Client.

2. Kernel Guard (ObjectOS Client):

   • Client Kernel checks: Does user have permission to edit 'Status'?
   • Kernel executes generic validation: Is 'Status' a valid option?
   • Transaction committed to SQLite (Local DB).

3. Synchronization (ObjectOS Sync):

   • Background process detects changes in SQLite.
   • Compresses change into an Operation Payload.
   • Sends payload to Server API.

4. Server Execution (ObjectOS Server):

   • Server Kernel authenticates the request.
   • Server Kernel runs "Before Update" triggers (e.g., Check credit limit).
   • Server passes AST to ObjectQL Compiler.

5. Persistence (ObjectQL):

   • Compiler generates UPDATE deals SET status = 'closed_won' ... for PostgreSQL.
   • Write is committed.
   • "After Update" triggers fire (send email to manager).