Schema-Driven Full Stack

How many times have you defined "User" in your application? Once in the database migration. Again in the ORM model. Again in the API response type. Again in the frontend state. Again in the form validation. Again in the API documentation. Six definitions of the same concept, all waiting to drift apart.

The Single Source of Truth

Schema-driven development inverts this pattern. You define your data model once, and the system generates everything else:

• Database tables — Migrations generated from schema changes
• REST endpoints — CRUD operations with proper HTTP semantics
• TypeScript types — Compile-time safety across the stack
• OpenAPI specifications — Always-accurate API documentation
• MCP tools — AI-callable interfaces automatically
• State managers — Frontend business logic that mirrors the API
• UI components — Forms, tables, validation rules

Change the schema — the entire stack regenerates. Not scaffolding you edit. Living code that stays in sync.

Real-World Use Cases

How Existing Tools Approach This

Many tools tackle pieces of this problem. Few attempt the full vertical integration:

The Two-Layer Architecture

True schema-driven development requires two fully separated layers, all generated from the same source:

1. Presentation Layer

React, React Native, Vue, Svelte — your choice. Generated components handle rendering but contain no business logic. A UserForm component knows how to render a user form, but not what to do when it's submitted.

2. State Manager Layer

Business logic lives here. The state manager knows that creating a user requires validation, then an API call, then updating local state, then showing a notification. It orchestrates, the presentation layer renders. It also handles API contract mirroring, caching, token management, and retry logic — the mechanical complexity of talking to the backend, generated from the same schema that defines the backend itself.

"Not scaffolding you edit. Living code that stays in sync."

Why This Matters

The average full-stack feature requires changes in 6-10 files across 3-4 layers. Each layer has its own conventions, its own testing requirements, its own opportunities for bugs. Developers spend more time on plumbing than on product.

Schema-driven development collapses this complexity. The schema is the feature definition. Everything else is derived. When generated code meets 80% of your needs perfectly and the remaining 20% has clear extension points, development velocity transforms.

How It Works

In an Application Operating System, you define a schema once as a JSON document. The system derives everything else:

// jsen-sym-schema-for-posts/schema.jsen.json
{
  "kSTable": "posts",
  "kJFields": {
    "kSType": "J",
    "kJKeys": {
      "slug": {
        "kSType": "S",
        "kRFormat": "^[a-z0-9]+(\\-[a-z0-9]+)*$",
        "kSBytes": "64",
        "kSRequired": "1"
      },
      "title": {
        "kSType": "S",
        "kSBytes": "255",
        "kSRequired": "1"
      },
      "body": {
        "kSType": "S",
        "kRFormat": "((^$)|(\\.(html|txt)$))",
        "kSRequired": "0"
      }
    }
  },
  "kSPrimary": "slug",
  "kAIndexes": ["title"]
}

Reference this schema in your service configuration:

// config.json
{
  "databases": {
    "blogdb": {
      "$aHCoreTables": {
        "posts": "jsen-sym-schema-for-posts"
      }
    }
  },
  "apis": {
    "blogapi": {
      "$aHRoutes": {
        // These routes are automatically generated from the schema:
        "$db:search:/blogdb.posts": {
          "path": ["jsen-sym-plugin-default-handle"],
          "expects": "$db:search:/blogdb.posts -> expects",
          "returns": "$db:search:/blogdb.posts -> returns"
        },
        "$db:select:/blogdb.posts": { ... },
        "$db:insert:/blogdb.posts": { ... },
        "$db:update:/blogdb.posts": { ... },
        "$db:delete:/blogdb.posts": { ... }
      }
    }
  }
}

The notation $db:search:/blogdb.posts -> expects tells the system to derive the API contract from the schema. What gets generated:

• Database table — With proper types, constraints, and indexes
• CRUD endpoints — Search, select, insert, update, delete
• API contracts — Request/response schemas for each operation
• Validation rules — Regex patterns, byte limits, required fields
• OpenAPI specification — Auto-generated documentation

Add a field to the schema — the database migrates, the API accepts it, the contract updates. Remove a field — the same cascade happens in reverse.

Beyond CRUD

Schema-driven doesn't mean only generated code. Complex business logic, custom endpoints, specialized UI — these still get written by hand. The schema handles the 80% that's predictable, freeing you to focus on the 20% that's unique.

The generated code provides extension points: plugin pipelines for before/after operations, customizable components for UI, middleware chains for endpoints. You're not fighting the framework; you're extending it.