Compiler Driven Development (CDD) is a development approach designed to eradicate the disconnect between: API specifications; server implementations; client SDKs; and command-line tooling.
Unlike traditional code generators—that treat outputs as disposable or read-only—CDD provides a complete, standalone compiler for each supported language. These compilers are fully CST-aware (Concreate Syntax Tree is a whitespace+comment aware Abstract Syntax Tree), allowing true bidirectional synchronization between existing hand-edited source code and OpenAPI specifications.
Traditional tools use naïve templating—if you regenerate, your custom code is overwritten.
The CDD ecosystem is fundamentally different. It utilizes language-specific, standalone compilers capable of full AST parsing, semantic diffing, and surgical patching.
The Core Guarantee: Every part of the generated codebase is fully editable. You are encouraged to open the generated routing files, model definitions, and CLI structures, and directly inject your business logic.
- When your specification changes, the CDD compiler reads your code, builds an AST, diffs it against the new spec, and safely patches in new endpoints or fields without touching your custom logic.
- When your codebase changes, the compiler reverse-engineers your structural updates back into a 100% accurate, authoritative OpenAPI specification.
flowchart TD
OAS["📄 OpenAPI v3 Spec"] <--> CDD{"⚙️ CDD Compiler"}
CDD <--> Codebase
subgraph Codebase ["💻 Application Codebase"]
direction TB
subgraph Outputs ["📦 Primary Outputs"]
direction TB
CLI["⌨️ CLI Tooling"]
SDK["📦 Client SDK"]
Server["🖥️ Server"]
%% Force vertical stacking inside the subgraph
CLI ~~~ SDK ~~~ Server
end
subgraph Core ["🔗 Core Architecture"]
direction TB
Models["🔗 Data Models"]
Routes["🔀 API Routes"]
Tests["🧪 Tests"]
%% Force vertical stacking inside the subgraph
Models ~~~ Routes ~~~ Tests
end
Mocks["🎭 API Mocks / Fakes"]
%% Simple dependency flow down the page
Outputs --> Core
Tests --> Mocks
end
style OAS fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
style CDD fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style Codebase fill:#fafafa,stroke:#9e9e9e,stroke-width:2px,stroke-dasharray: 5 5
style Outputs fill:#e8f5e9,stroke:#43a047,stroke-width:2px
style Core fill:#fff3e0,stroke:#f57c00,stroke-width:2px
The CDD lifecycle supports continuous evolution from any starting point:
- Generate: Scaffold servers, SDKs, or CLIs from a central specification.
- Edit: Developers write real, unconstrained code directly in the generated files.
- Extract: Reverse-compile the edited code to produce an updated OpenAPI spec.
- Sync: Apply new specification changes seamlessly into the existing, hand-edited codebase.
Every supported language operates on the same core CDD philosophies but is powered by a dedicated, native compiler tailored to that language's specific AST, idioms, and package management.
All implementations share a standardized CLI interface (cdd [subcommand]), acting as a universal toolchain.
| Repository | Language | Client; Client CLI; Server | Extra features | Standards | CI Status |
|---|---|---|---|---|---|
cdd-c |
C (C89) | Client; Client CLI; Server | FFI | Swagger 2.0 & OpenAPI 3.2.0 |  |
cdd-cpp |
C++ | Client; Client CLI; Server | Upgrades Swagger & Google Discovery to OpenAPI 3.2.0 | Google Discovery; Swagger 2.0 & OpenAPI 3.2.0 |  |
cdd-csharp |
C# | Client; Client CLI; Server | CLR | Swagger 2.0 & OpenAPI 3.2.0 |  |
cdd-go |
Go | Client; Client CLI; Server | Swagger 2.0 & OpenAPI 3.2.0 |  |
|
cdd-java |
Java | Client; Client CLI; Server | Swagger 2.0 & OpenAPI 3.2.0 |  |
|
cdd-kotlin |
Kotlin (ktor for Multiplatform) | Client; Client CLI; Server | Auto-Admin UI | Swagger 2.0 & OpenAPI 3.2.0 |  |
cdd-php |
PHP | Client; Client CLI; Server | Swagger 2.0 & OpenAPI 3.2.0 |  |
|
cdd-python |
Python | N/A (server building blocks) | CLI ↔ SQL ↔ Pydantic ↔ docs ↔ JSON-schema | N/A |  |
cdd-python-all |
Python | Client; Client CLI; Server | Swagger 2.0 & OpenAPI 3.2.0 |  |
|
cdd-ruby |
Ruby | Client; Client CLI; Server | Swagger 2.0 & OpenAPI 3.2.0 |  |
|
cdd-rust |
Rust | Client; Client CLI; Server | Swagger 2.0 & OpenAPI 3.2.0 |  |
|
cdd-sh |
Shell (/bin/sh) | Client; Client CLI; Server | Swagger 2.0 & OpenAPI 3.2.0 |  |
|
cdd-swift |
Swift | Client; Client CLI; Server | Swagger 2.0 & OpenAPI 3.2.0 |  |
|
cdd-ts |
TypeScript | Client; Client CLI; Server | Auto-Admin UI; Angular; React; Vue; fetch; Axios; Node.js | Swagger 2.0 & OpenAPI 3.2.0 |  |
A true ecosystem requires standardized tooling. Once a developer learns the CDD toolchain, they can synchronize architecture across the entire polyglot stack.
--help: Print help information.--version: Print version information.--input, -i(or-f): Target file, directory, or OpenAPI spec.--output, -o: Destination path for generation or sync.
Generate a client SDK and a corresponding command-line interface (CLI) from an OpenAPI specification.
Usage:
cdd-cpp from_openapi to_sdk_cli -i <spec.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_sdk_cli --input-dir <specs_dir> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_sdk -i <spec.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_sdk --input-dir <specs_dir> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_server -i <spec.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_server --input-dir <specs_dir> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
Options:
-i, -f, --input Path or URL to the OpenAPI specification.
--input-dir Directory containing OpenAPI specifications.
-o, --output Output file or directory path.
--tests Generate integration tests and mocks.
--no-github-actions Do not generate GitHub Actions scaffolding.
--no-installable-package Do not generate installable package scaffolding.
Generate a client SDK from an OpenAPI specification.
Usage:
cdd-cpp from_openapi to_sdk_cli -i <spec.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_sdk_cli --input-dir <specs_dir> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_sdk -i <spec.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_sdk --input-dir <specs_dir> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_server -i <spec.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_server --input-dir <specs_dir> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
Options:
-i, -f, --input Path or URL to the OpenAPI specification.
--input-dir Directory containing OpenAPI specifications.
-o, --output Output file or directory path.
--tests Generate integration tests and mocks.
--no-github-actions Do not generate GitHub Actions scaffolding.
--no-installable-package Do not generate installable package scaffolding.
Generate server boilerplate, models, and routing logic from an OpenAPI specification.
Usage:
cdd-cpp from_openapi to_sdk_cli -i <spec.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_sdk_cli --input-dir <specs_dir> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_sdk -i <spec.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_sdk --input-dir <specs_dir> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_server -i <spec.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_openapi to_server --input-dir <specs_dir> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
Options:
-i, -f, --input Path or URL to the OpenAPI specification.
--input-dir Directory containing OpenAPI specifications.
-o, --output Output file or directory path.
--tests Generate integration tests and mocks.
--no-github-actions Do not generate GitHub Actions scaffolding.
--no-installable-package Do not generate installable package scaffolding.
Parse the existing codebase and extract an authoritative OpenAPI specification.
Usage:
cdd-cpp to_openapi -i <path/to/code> [-o <spec.json>]
Options:
-i, -f, --input Path to source code directory or file.
-o, --output Output file or directory path.
Convert an OpenAPI specification into a localized, documentation-optimized JSON format.
Usage:
cdd-cpp to_docs_json [--no-imports] [--no-wrapping] -i <spec.json> [-o <docs.json>]
Options:
-i, -f, --input Path or URL to the OpenAPI specification.
-o, --output Output file or directory path.
--no-imports Omit the imports field.
--no-wrapping Omit the wrapper fields.
Launch a JSON-RPC server for editor and tool integrations.
Usage:
cdd-cpp serve_json_rpc [-p|--port <port>] [-l|--listen <address>]
Options:
-p, --port Port to listen on.
-l, --listen Address to listen on.
Run the Model Context Protocol server via stdio.
Usage:
cdd-cpp mcp
Start a Model Context Protocol (MCP) STDIO server.
Generate a client SDK and a corresponding command-line interface (CLI) from a Google Discovery JSON.
Usage:
cdd-cpp from_google_discovery to_sdk_cli -i <discovery.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_google_discovery to_sdk -i <discovery.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
Generate a client SDK from a Google Discovery JSON.
Usage:
cdd-cpp from_google_discovery to_sdk_cli -i <discovery.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
cdd-cpp from_google_discovery to_sdk -i <discovery.json> -o <target_directory> [--no-github-actions] [--no-installable-package] [--tests]
Synchronize an OpenAPI specification with source code.
Usage:
cdd-cpp sync -i <dir> -o <file>
Options:
-i, -f, --input Path to source code directory.
-o, --output Path to OpenAPI spec file.
- Google Discovery Support: Uniquely supports parsing and generating code from Google Discovery JSON (
from_google_discovery), enabling integration with older Google APIs. - Batch Processing: The
--input-dir <specs_dir>option enables generation from multiple OpenAPI specification files in a single pass. - Testing Scaffolding:
--testsgenerates integration tests and API mocks using C++ testing frameworks (like GTest). - CI/CD Scaffolding: By default, generates GitHub Actions workflows (
.github/workflows/ci.yml) for the resulting project. This can be suppressed via--no-github-actions. - Installable Packages: Automatically generates
CMakeLists.txtmaking the outputs ready-to-use C++ libraries or binaries. This can be suppressed via--no-installable-package.
With Compiler Driven Development, specifications and code are no longer loosely coupled artifacts. They are strict, isomorphic reflections of one another, maintained by dedicated standalone compilers.
Choose your language ecosystem above and start treating your architecture as a seamlessly compiled, endlessly editable whole.
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.