Skip to main content

Architecture

ClassCAD is designed as a headless, programmable CAD backend.
Its architecture separates CAD logic, execution, and integration concerns in order to provide:

  • Stability over long-lived CAD systems of CAD logic
  • Deterministic and reproducible execution of CAD logic
  • Independence from UI frameworks and client platforms
  • Flexible deployment (desktop, server, cloud, web)

This document describes the conceptual architecture of ClassCAD and how its main building blocks interact.

High-Level Architecture​

At a high level, ClassCAD consists of:

  • A C++ runtime that executes CAD logic
  • A domain-specific programming language for CAD business logic
  • A plugin-based extension system
  • A stable API surface consumed by external applications
  • Optional proxy and wrapper layers for integration

ClassCAD itself is not an end-user application.
It is intended to be embedded into other systems and products.

Core Building Blocks​

ClassCAD Runtime​

The ClassCAD Runtime is the execution environment for all ClassCAD applications.

Its responsibilities include:

  • Managing the lifecycle of ClassCAD processes
  • Compiling and executing ClassCAD programs
  • Maintaining the internal CAD model
  • Dispatching API requests
  • Providing controlled access to system services

The runtime is implemented in C++ and runs on:

  • Windows
  • Linux (Ubuntu)
  • WebAssembly (for browser-based scenarios)

From an architectural perspective, the runtime acts as the central authority: it controls execution, data access, and integration boundaries.

Virtual Machine and Execution Model​

ClassCAD logic is written in a dedicated, object-oriented language and compiled into bytecode.

This bytecode is executed by the ClassCAD Virtual Machine (CCVM), which ensures:

  • deterministic and reproducible execution of CAD logic
  • Isolation from external runtimes
  • Stable behavior over time

This approach allows ClassCAD applications to remain unchanged even when internal components evolve.

Plugin System (Service Libraries)​

The runtime can be extended through a plugin mechanism, also referred to as service libraries.

Plugins:

  • Developed and maintained exclusively by the ClassCAD team
  • Are implemented in C++
  • Register well-defined service functions with the runtime
  • Are accessed indirectly by ClassCAD programs via the runtime

Typical responsibilities provided by plugins include:

  • Geometry kernel integration
  • 2D and 3D constraint solving
  • Additional system-level services

This design ensures that:

  • ClassCAD programs do not depend directly on specific libraries
  • Core logic remains stable even if plugins are replaced or upgraded

ClassCAD Programs (cclasses)​

cclasses Overview​

All CAD and business logic in ClassCAD is implemented as classes written in the ClassCAD language, commonly called cclasses.

Key characteristics:

  • One class per file
  • Object-oriented design
  • Executed and managed by the runtime
  • Instantiated at runtime to form the CAD model

From an architectural perspective, cclasses define what the CAD system does, while the runtime defines how it is executed.

System Classes (SDK)​

System Classes form the foundational layer for all ClassCAD applications.

They:

  • Provide reusable, generic functionality
  • Define stable APIs
  • Act as an SDK for application developers

System classes are shipped together with the runtime and serve as the base upon which all custom solutions are built.

Application Classes​

Application Classes implement the actual CAD business logic.

They:

  • Currently developed by the ClassCAD team and selected enterprise customers
  • Contain domain-specific rules and workflows
  • Build on system classes
  • Define the API surface used by external applications

A complete ClassCAD application can be packaged and deployed as a single unit containing all required classes.

Example: BaseModeling​

BaseModeling is a reference application provided with ClassCAD.

It demonstrates:

  • Feature modeling
  • Assembly building
  • Reusable CAD APIs

Architecturally, it behaves like any other ClassCAD application and can be extended or integrated into custom solutions.

API Concept​

API as Stable Contract​

The ClassCAD API is not a separate technical layer, but a conceptual contract.

Important characteristics:

  • API methods are implemented as static methods in cclasses
  • External systems call these methods via wrappers
  • API methods operate on the current CAD model
  • Internal data structures may change without affecting the API

This separation allows ClassCAD to evolve internally while keeping integrations stable.

API Request Flow (Conceptual)​

From a high-level perspective, an API request follows this path:

  1. An external application calls an API method
  2. The request reaches the ClassCAD runtime
  3. The runtime prepares and validates the request
  4. The virtual machine executes the corresponding class method
  5. The result is returned to the caller

All access to the CAD model is mediated by the runtime.

Client Applications​

ClassCAD is designed to be embedded into a wide range of client applications, all of which interact with the system exclusively through the public API and API wrappers.

These clients can include:

  • Backend services and automation pipelines
  • Web applications and product configurators
  • Desktop or enterprise systems
  • Fully interactive CAD applications

A concrete example is buerligons, an interactive, web-based CAD application developed by AWV Informatik AG.
buerligons uses ClassCAD exclusively via its public API wrappers and demonstrates that even interactive CAD editors can be built on top of the same architectural foundations as non-interactive or automated clients.

From an architectural perspective, buerligons does not have any special access to ClassCAD.
It behaves like any other external client application and serves as a real-world validation of the API-driven architecture.

Deployment and Operation Modes​

Proxy-Based Operation​

The most common deployment model uses ClassCAD as a WebSocket client behind a proxy.

In this setup:

  • ClassCAD runs as an isolated C++ process
  • A proxy server mediates all external communication
  • External systems never communicate with ClassCAD directly

AWV provides a reference proxy implementation: @classcad/node.

This approach enables:

  • Secure isolation
  • Process management
  • Horizontal scaling
  • Language-agnostic client access

WebAssembly-Based Operation (Browser)​

ClassCAD can also be operated as a WebAssembly (WASM) runtime for browser-based scenarios.

In this setup:

  • The ClassCAD runtime is compiled to WebAssembly
  • Execution happens inside the browser environment
  • No native runtime process or proxy server is required
  • The runtime typically runs in a Web Worker for isolation

External applications interact with the runtime through the same API wrappers as in server-based deployments. The API surface and CAD logic remain identical.

This operation mode is particularly suited for:

  • Web-based CAD applications
  • Client-side previews and validation
  • Offline or sandboxed execution scenarios

From an architectural perspective, WebAssembly is an alternative execution environment, not a different architecture.

Alternative Modes (Experimental)​

Other operation modes exist but are currently experimental:

  • ClassCAD as a WebSocket server
  • ClassCAD as an HTTP server

These modes may become relevant in future deployments but are not yet considered standard.

API Wrappers​

Comming soon. This is work in progress.

To simplify integration, ClassCAD provides API wrappers for multiple ecosystems:

  • JavaScript / Node.js
  • Python
  • .NET

Wrappers:

  • Do not add functionality
  • Do not change the API
  • Only improve developer experience

They translate native language calls into ClassCAD API requests.

Architecture Overview​

This diagram provides a high-level view of the ClassCAD architecture and how different operation modes fit together.

It is intentionally non-technical and focuses on the main architectural building blocks and communication paths.

Architecture Diagram​

overview

How to Read This Diagram​

  • Client applications interact only through API wrappers
  • API wrappers trigger execution inside the ClassCAD Runtime
  • The runtime executes System Classes and Application Classes
  • Application Classes build on System Classes
  • Plugins extend the runtime by registering services
  • Classes never talk to plugins directly; all access is mediated by the runtime
  • Proxy-based and WebAssembly-based execution are alternative operation modes

This diagram communicates architectural responsibilities, not implementation details.

Architectural Principles​

The ClassCAD architecture is guided by the following principles:

  • Headless by design
    No UI, no interaction logic, no client assumptions

  • Strict separation of concerns
    Runtime, logic, services, and integration are clearly separated

  • deterministic and reproducible execution of CAD logic
    Same input always produces the same result

  • Stable APIs
    External contracts remain stable even as internals evolve

  • Extensibility through control
    Powerful extension points without exposing internal complexity

Summary​

ClassCAD is architected as a CAD backend platform, not as a traditional CAD system.

Its architecture enables:

  • Long-lived CAD logic
  • Automated and cloud-based CAD workflows
  • Integration into modern web and enterprise systems

By separating execution, logic, and integration, ClassCAD provides a robust foundation for scalable and future-proof CAD solutions.

Development Responsibility and Extension Model​

ClassCAD distinguishes clearly between system-level extensibility and application-level customization.

  • Plugins (Service Libraries) extend the ClassCAD runtime with core capabilities such as solid modeling, constraint solving, and other system-level services.
    Plugins are developed and maintained exclusively by the ClassCAD team and are not intended as a third-party extension mechanism.

  • Application Classes implement CAD business logic on top of the runtime and system classes.
    At present, application classes are developed by the ClassCAD team and selected enterprise customers.

This model ensures architectural consistency, controlled evolution, and compatibility across ClassCAD deployments while enabling tailored CAD solutions within clearly defined boundaries.