How people reach it
page · navigation · flow · messagesAppling is a declarative language for business applications: data, rules, behavior, APIs and pages in one validated model that people and AI share. Write it from scratch, or let an AI agent derive it from the project you already have.
Each target is an installable extension that turns the same model into a draft project. What a generator cannot write becomes a task in a registry, for you or an AI to finish.
@appling/codegen-djangoA Django 6.1 project managed by uv: one app per module, models, behavior as functions and signals, a REST framework API and pages.
All five layersRead the docs →@appling/codegen-ashAn Ash 3 project on AshPostgres, built with Ash's own generators: resources, actions, state machines, background jobs, a JSON:API and Phoenix LiveView pages.
All five layersRead the docs →@appling/codegen-goPlain Go packages, one per module, without a framework: types, invariants, derived fields, actions with their state transitions, errors and events.
Domain and behaviorRead the docs →@appling/codegen-rustA library crate with one module per Appling module, using serde, rust_decimal and chrono, with the same coverage as Go.
Domain and behaviorRead the docs →Another framework? Code generation runs through extensions; write your own against the same graph.
An AI agent reads your code, whether it is Django, Ash, Rails, Spring, Express or any other codebase with a data model, and writes the Appling model for it. It never leaves the model invalid, and asks you when the code allows two readings.
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.
page · navigation · flow · messagesinterfacequery · projection · external · usecaseevent · action · machine · jobenum · value · entity · invariant · policymodule · role · actor · tenant · migrationWrite the model in plain .appling files. The text is the canonical source.
Parsed and linked across files and modules, every element by its qualified name.
Layer rules, exports and migrations are checked on every build.
Explore and edit the graph in the IDE, review AI proposals, and generate a Django, Ash, Go or Rust project, all from the same source.
The command line, the IDE, the AI and the generators all work on one validated model and change it through the same edit operations.
@appling/cliCheck, format, dump the graph, cut releases and generate projects. Exit codes made for CI.
$ npx appling check modelsRead the docs →@appling/ideThe text and the zoomable graph side by side. Edit in either; every edit is validated and lands as one undoable step.
$ npx @appling/ide modelsRead the docs →@appling/aiAn MCP server for any client and a chat in the IDE. AI changes pass validation and arrive as proposals you review.
$ npx appling-mcp modelsRead the docs →@appling/codegen-django, -ash, -go, -rustA draft Django, Ash, Go or Rust project from the model, plus a task registry of everything left for you or an AI to write.
$ npx appling generate --planRead the docs →@appling/modelA release snapshots the graph. Later renames and type changes become migration steps that generated projects apply without losing data.
$ npx appling release 1.0.0Read the docs →@appling/langDiagnostics, completion, go to definition, rename, hover and canonical formatting in any editor that speaks LSP.
$ appling-language-server --stdioRead the docs →The same sales module, as text and as the graph Appling builds from it.
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 } }
[CUSTOMER QUOTE: what Appling changed for their team]
[CUSTOMER QUOTE: a concrete before and after]
Every tool reads the same resolved semantic graph and changes it through the same edit operations. The graph came first, then the IDE and code generation grew from it in parallel. Every stage below has shipped.
@appling/ide, @appling/ai@appling/codegen, codegen-django, codegen-ash@appling/lang, @appling/modelDone: the CLI dumps the graph of the examples and an edit operation survives fmt unchanged.
npx @appling/ide opens the workspace in the browser: an LSP backed editor and the zoomable graph, with selection synced between them.
Plan, step runner, map contract, task registry and prerequisite checks behind appling generate.
Django and Ash maps for entities, enums, value types, invariants and policies.
Edit elements and attributes in the graph. Migration entries appear once a release exists.
An MCP server for any client plus a chat panel. AI changes pass validation and arrive as reviewable diffs.
Actions, state machines, events, jobs, queries, projections, use cases and interfaces.
Test skeletons for invariants, preconditions, transitions and policies.
AI picks open registry entries, implements them, runs the related tests and marks them done.
makemigrations and mix ash.codegen, fed with Appling rename and retype steps so nothing is guessed as remove plus add.
Point the tools 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.
@appling/ide opens the text and the graph side by side in your browser.
generate writes a draft project for every target in appling.config.json.