Core Values

ObjectStack is built upon three non-negotiable architectural values. These are not just "features"; they are the constraints that guide every design decision we make.

1. Protocol-Driven: Intent over Implementation

The fundamental thesis of ObjectStack is that application logic should be defined by declarative data, not imperative code.

The Problem with "Code-First"

In modern development, the "Intent" (e.g., “This field is a required email address”) is often scattered across three layers:

1. Database: SQL constraints (NOT NULL).
2. Backend: ORM validation (e.g., TypeORM decorators).
3. Frontend: UI validation (e.g., React Hook Form + Zod).

When the business requirement changes, you must update code in three places. This is Implementation Coupling.

The Protocol-Driven Solution

ObjectStack centralizes the "Intent" into a single Protocol Definition (JSON/YAML). The implementation layers (React, Node.js, SQL) act merely as Runtime Engines that interpret this protocol.

• The UI is a Projection: ObjectUI does not "build" a form; it projects the ObjectQL schema into a visual representation.
• The API is a Consequence: You do not write endpoints; ObjectOS generates the secure graph based on the access control protocol.

Analogy: Think of ObjectStack as a Web Browser. You send it HTML (Protocol), and it renders a page. You don't rewrite the browser engine (C++) every time you want to change the text on a website.

2. Local-First: Ownership & Zero Latency

For the past decade, "Cloud-Native" has been the gold standard. While it solved deployment issues, it introduced a new problem: The User rents their access to data.

If the server is slow, the app is slow. If the internet is down, the app is dead.

The "Seven Hops" Problem

In a traditional Cloud app, a simple button click travels through: Click -> Wi-Fi -> ISP -> Cloud Load Balancer -> Web Server -> Database -> Query Execution ...and then all the way back.

The Local-First Solution

ObjectStack apps are designed to read and write to a Local Database (embedded within the client environment) first. Click -> Local DB -> UI Update (0ms Latency).

The synchronization with the cloud happens in the background, asynchronously.

1. Instant Response: The UI reacts immediately (optimistic UI), making enterprise apps feel as snappy as native desktop software.
2. Offline Capability: Field workers, airplanes, or spotty connections are no longer blockers.
3. Data Sovereignty: The data physically resides on the user's device. The cloud acts as a synchronization hub, not the sole gatekeeper.

3. Database Agnostic: The "Universal Compiler"

Vendor lock-in is the enemy of longevity. A business application usually outlives the database technology it was originally built on.

ObjectQL treats the underlying database as an Implementation Detail.

The Compiler Approach

Instead of being a runtime wrapper (like an ORM), ObjectQL functions as a Compiler.

1. Input: ObjectQL Abstract Syntax Tree (AST).
2. Process: Compile AST into dialect-specific SQL.
3. Output: Highly optimized queries for the target target.

This architecture allows for radical flexibility:

• Dev: Run on SQLite (Zero setup, single file).
• Prod: Run on PostgreSQL (Robust, scalable).
• Edge: Run on Cloudflare D1 (Distributed).
• Legacy: Connect to an existing Oracle/SQL Server (Integration).

You change the Driver, not the Code.

Summary

Value	The Old Way	The ObjectStack Way
Architecture	Code-Driven (Imperative)	Protocol-Driven (Declarative)
Logic Location	Scattered (DB + API + UI)	Centralized (JSON/YAML Schema)
Data Access	Cloud-Dependent (Online Only)	Local-First (Offline + Sync)
Storage	Locked to Vendor	Database Agnostic

By adhering to these values, we build software that is resilient to change, respectful of user time, and technically sovereign.