ObjectQL is built with a modular architecture that separates the data definition (Metadata) from the execution engine (Driver). This design allows applications to run on different database stacks (SQL vs NoSQL) without changing the business logic.
An ObjectQL application consists of three main layers:
- Metadata Layer: JSON/YAML files that define the shape of your data (
.object.yml) and operations. - Core Engine: The
ObjectQLclass that loads metadata, validates requests, and orchestrates execution. - Driver Layer: Adapters that translate ObjectQL requests into database-specific queries (SQL, Mongo Protocol, etc.).
The project is structured as a monorepo with strict dependency rules to ensure scalability and maintainability.
@objectql/types: The shared contract. Contains all interfaces (ObjectConfig,ObjectQLDriver). Has zero dependencies.@objectql/parser: Responsible for parsing YAML/JSON into the internal AST.@objectql/core: The main runtime. It depends ontypesandparser.@objectql/driver-*: Database adapters. They implement interfaces fromtypesbut do not depend oncore(avoiding circular dependencies).
In traditional ORMs (like TypeORM or Prisma), you define classes/schema in code. In ObjectQL, the schema is data itself. This allows:
- Dynamic schema generation at runtime.
- Building "No-Code" table designers.
- Hot-reloading of data structure without recompiling.
ObjectQL uses a unified JSON-based query language (AST). This allows frontends, AI agents, or external systems to send complex queries (filters, expand, aggregates) in a safe, serializable format.
- Hooks: Intercept standard CRUD operations (e.g., "Before Create", "After Update") to enforce business rules.
- Actions: Define custom RPC methods (e.g., "Approve Invoice") exposed via the API.