Philosophy

FLXBL is built on a simple principle: you should focus on what makes your application unique—your domain model and business logic—while the platform handles everything else.

The Vision

Traditional backend development requires you to build and maintain a mountain of infrastructure code: database schemas, API endpoints, authentication, authorization, migrations, and more. This boilerplate takes time away from what actually matters—solving your business problems.

FLXBL inverts this equation. Define your entities and relationships, and the platform automatically generates:

• REST API with full CRUD operations, filtering, and pagination
• GraphQL API with type-safe queries and mutations
• Graph database storage with native relationship traversal
• Authentication & authorization with roles, permissions, and API keys
• Webhooks for event-driven integrations
• Schema versioning with automatic migrations

flowchart TB
    subgraph you [What You Build]
        direction TB
        BL[Business Logic]
        FE[Frontend/Mobile]
        WF[Custom Workflows]
    end
    
    subgraph flxbl [What FLXBL Provides]
        direction TB
        API[REST & GraphQL APIs]
        AUTH[Authentication & RBAC]
        DATA[Graph Database]
        SCHEMA[Schema Management]
        HOOKS[Webhooks & Events]
        CLI[CLI + SDK Workflows]
    end
    
    you --> flxbl
    API --> DATA
    AUTH --> DATA
    SCHEMA --> DATA

Domain-Driven, Not Database-Driven

With FLXBL, you think in terms of your domain model—the real-world concepts your application deals with—not database tables and foreign keys.

Consider an e-commerce application. Instead of designing tables with foreign key columns, you describe the domain:

• A Customer can place multiple Orders
• An Order contains multiple Products
• A Product belongs to one or more Categories
• A Customer can write Reviews for Products they've purchased

These are relationships—first-class citizens in FLXBL, not afterthoughts implemented as foreign key columns.

Graph-First Thinking

Under the hood, FLXBL stores your data in Neo4j, a graph database. This isn't just an implementation detail—it fundamentally changes what's possible:

flowchart TB
    subgraph traditional [Traditional: Foreign Keys]
        U1[User Table]
        P1[Post Table]
        C1[Comment Table]
        U1 -.->|userId FK| P1
        P1 -.->|postId FK| C1
    end
    
    subgraph graphdb [FLXBL: Graph Relationships]
        U2([User])
        P2([Post])
        C2([Comment])
        U2 ==>|AUTHORED| P2
        P2 ==>|HAS_COMMENT| C2
        U2 ==>|WROTE| C2
    end

Why Graphs Over Foreign Keys?

With relationships as first-class citizens, queries like "find all products reviewed by customers who also bought this product" become simple traversals instead of complex multi-table joins.

Your Backend, Your Logic

FLXBL provides the data layer and APIs—but your business logic remains yours. The platform is designed to be consumed by your applications:

• Build frontends that call the generated REST or GraphQL APIs
• Create backend services that implement custom business rules, then persist data through FLXBL
• Set up webhooks to trigger workflows when data changes
• Use coding agents through CLI context, JSON output, and dry-run previews

Think of FLXBL as the foundation. You're not locked into a framework—you build whatever you need on top, in whatever language or technology you prefer.

Multi-Tenant by Design

Every FLXBL deployment is multi-tenant from day one. Each tenant gets:

• Complete data isolation—tenants cannot access each other's data
• Independent schemas—each tenant can have their own data model
• Scoped API keys—fine-grained access control per application
• Separate configurations—identity settings, webhooks, and more

Whether you're building a SaaS product with many customers or a single application with strict data boundaries, the multi-tenant architecture has you covered.

Agent-Friendly Development

FLXBL exposes a dedicated CLI that lets coding agents understand your tenant, schema, APIs, and available operations through stable shell commands. In tools like Cursor, Codex, Claude Code, or CI scripts, you can:

• Load schema context with flxbl context --full --json
• Validate schema files before publishing them
• Preview data and admin mutations with --dry-run --json
• Generate TypeScript interfaces and Zod schemas with flxbl generate

Agents get full context without bespoke protocol glue, and humans can run the same commands locally to inspect or reproduce every operation.

What This Means for You

When you adopt FLXBL, your development workflow changes:

1. Model your domain—define entities, fields, and relationships
2. Let FLXBL generate the APIs—REST and GraphQL, ready to use
3. Build your application—frontend, business logic, integrations
4. Evolve your schema—FLXBL handles migrations automatically

No more writing boilerplate CRUD endpoints. No more managing database migrations manually. No more implementing authentication from scratch. Focus on what your application actually does.

Next Steps

• Quick Start—set up FLXBL and create your first schema
• Schema Design—learn how to model entities and relationships
• LLM-Friendly CLI—use coding agents safely with FLXBL
• API Reference—explore the generated REST and GraphQL APIs