Open source · MIT licensed

Define once. Reference outward. Validate always.

Appling is a declarative language that describes a business application as one validated model. That text is the single source of truth: Appling visualizes it as a living graph and generates code from it, so people and AI always build from the same model.

Get startednpm i -D @appling/cli

entity Orderaction PlaceOrderVisualizeGenerate codesales.applingbilling.applingsingle source of truth

Architecture

Five layers, one model

Each concept is defined once, in the layer that owns it. References only point down the layers, and modules only see what other modules export.

L5 Experience

How people reach it

page · navigation · flow · messages

L4 Interfaces

How programs reach it

interface

L3 Application

How capabilities are organized

query · projection · external · usecase

L2 Behavior

What can happen

event · action · machine · job

L1 Domain

What exists

enum · value · entity · invariant · policy

Cross cutting

Modules, access, evolution

module · role · actor · tenant · migration

How it works

From text to a living graph

Text

Write the model in plain .appling files. The text is the canonical source.

Graph

Parsed and linked across files and modules, every element by its qualified name.

Validated

Layer rules, exports and migrations are checked on every build.

Visualize and generate

Explore and simulate the graph, edit with AI, and generate code, all from the same source.

Example

One file in, one linked model out

The same sales module, as text and as the graph Appling builds from it.

sales.applingvalid

module sales {
  export Order

  enum OrderStatus {
    draft
    placed
  }

  entity Order {
    reference: String unique
    status: OrderStatus state default draft
  }

  action PlaceOrder on Order {
    requires { reference != "" }
  }

  machine OrderFlow on Order.status {
    transition draft -> placed via PlaceOrder
  }
}

The graph

What people say

Proof from real projects

[CUSTOMER QUOTE: what Appling changed for their team]

[NAME], [ROLE], [COMPANY]

[CUSTOMER QUOTE: a concrete before and after]

[NAME], [ROLE], [COMPANY]

Example repositoryBrowse full models on GitHubalex20465/appling/examples →

Roadmap

One graph, every tool on top

Every tool reads the same resolved semantic graph and changes it through the same edit operations. The graph comes first, then the IDE and code generation grow from it in parallel.

IDE

@appling/ide, @appling/ai

Code generation

@appling/codegen, codegen-django, codegen-ash

Stage 1

Foundation

@appling/lang, @appling/model

Semantic graphPlain, serializable nodes and typed edges. Zoom aggregation, such as module to module dependencies, is computed.
Edit operationsAdd, rename, retype, remove and set attribute, each a minimal text edit that is rejected if it fails validation.
Releasesappling release writes a graph snapshot. Edits to released L1 elements append migration steps automatically.
Language serverLangium's LSP services, exported as @appling/lang/lsp.
Expression typingNames and types resolved inside expressions where possible.

Done when the CLI can dump the graph of the examples and an edit operation survives fmt unchanged.

Stage 2

A1IDE

Read only IDE

npx @appling/ide opens the workspace in the browser: an LSP backed editor and the zoomable graph, with selection synced between them.

B1Code generation

Core

Plan, step runner, map contract, task registry and prerequisite checks behind appling generate.

B2Code generation

Domain maps

Django and Ash maps for entities, enums, value types, invariants and policies.

Stage 3

A2IDE

Editing

Edit elements and attributes in the graph. Migration entries appear once a release exists.

A3IDE

AI

An MCP server for any client plus a chat panel. AI changes pass validation and arrive as reviewable diffs.

B3Code generation

Behavior to interface maps

Actions, state machines, events, jobs, queries, projections, use cases and interfaces.

B4Code generation

Tests

Test skeletons for invariants, preconditions, transitions and policies.

Stage 4

B5Code generation

Registry skill

AI picks open registry entries, implements them, runs the related tests and marks them done.

B6Code generation

Migrations

makemigrations and mix ash.codegen, fed with Appling rename and retype steps so nothing is guessed as remove plus add.

Later

VS Code extensionBuilt on @appling/lang/lsp.
Appling SyncRegenerate code from the model using the registry.
Reverse engineeringDerive an Appling model from an existing application.
More targetsGo and Rust as extensions.

Get started

Install, check, format

The appling command checks your models and writes them in canonical form. Point it at a folder; files that reference each other load as one workspace.

check validates every .appling file and exits with 1 when it finds errors.

fmt rewrites files into canonical form. A second run changes nothing.

terminal

# add the CLI to your project$ npm i -D @appling/cli# validate every model$ npx @appling/cli check models# write canonical form$ npx @appling/cli fmt models