Architecture Breakdown

The Trinity Architecture Deep Dive

The Trinity Architecture

The core innovation of ObjectStack is the strict separation of concerns into three autonomous layers. This is what we call the Trinity Architecture.

This architecture is designed to solve the "Monolith vs. Microservice" debate by offering a Modular Monolith approach that is easy to start but ready to scale.

High-Level Diagram

graph TD
    User[User / Client] --> UI[Layer 3: ObjectUI (View)]
    
    subgraph "The Application Runtime"
        UI --> OS[Layer 2: ObjectOS (Platform)]
        OS --> QL[Layer 1: ObjectQL (Engine)]
    end
    
    subgraph "External Storage"
        QL --> DB1[(Postgres)]
        QL --> DB2[(Redis)]
        QL --> DB3[(Excel/File)]
        QL --> API((Ext. API))
    end

Layer 1: The Data Engine (ObjectQL)

Role: Virtualization & Abstraction Input: ObjectQL Queries (JSON/YAML) Output: Standardized Data (JSON)

This layer knows nothing about "Users", "Permissions", or "UI". Its only job is to efficiently translate abstract queries into physical storage commands.

• Responsibility:
  • Query Planning & Optimization.
  • Connection Pooling.
  • Data Type normalization.
  • Transaction management.

Layer 2: The Business Platform (ObjectOS)

Role: Governance & Orchestration Input: HTTP Requests / RPC Output: Secure Business Objects

This layer sits "above" the Data Engine. It injects context. It knows who is asking and why.

• Responsibility:
  • Authentication: Validating the JWT/Session.
  • Authorization: Injecting RBAC filters into the ObjectQL query.
  • Interceptors: Running logic "Before Create" or "After Update".
  • Workflows: Triggering background jobs based on data changes.

Layer 3: The Projection Layer (ObjectUI)

Role: Interaction & Presentation Input: Layout Manifests Output: DOM / Native Components

This layer is purely presentational. It consumes the capabilities of the Platform and the data of the Engine to render a usable interface.

• Responsibility:
  • State Management (Client-side).
  • Optimistic UI updates.
  • Client-side validation (derived from Schema).
  • Accessibility compliance (ARIA).

Why this Separation Matters?

1. Independent Scaling

You can scale the Engine (Read Replicas) independently of the Platform (Authentication Nodes).

2. Team Specialization

• Data Engineers work on Layer 1 (Optimizing drivers, Schema design).
• Backend Developers work on Layer 2 (Workflows, Permissions).
• Frontend Developers work on Layer 3 (Custom components, Theming).

3. Replaceability

You can completely replace the UI layer (e.g., switch from React to a Chat Interface) without touching a single line of business logic or data schema.