Skip to content

A sovereign unit of functionality.

Zero Distance Architecture, One process where Data, Logic, and UI are co-located. Build as Self-Contained-System, Monolith or Microservices. lanck makes the distance between them zero.

Building lanck

Four constants you'll feel in every line of code you write.

01

The database is the runtime

Your service compiles to a single .wasm that the DB loads into its own process. No separate app server, no deploy artifact other than the binary. The DB is your container.

02

Direct access to the store

Handlers query the embedded store through a typed query builder. No ORM, no socket, no JSON wire between code and data. Reads are direct memory access, predictably fast.

03

You own the response shape

The same handler can render HTML fragments for a hypermedia frontend (HTMX, Alpine, Datastar, anything DOM-swapping), return JSON for a classic API, or stream raw bytes. The wire format is a choice you make per route.

04

Coordination is event-driven

WASM services can't open sockets. Cross-service work happens through SSE topics on the host bus, pub / sub, observable, no point-to-point coupling. Which is what you wanted at the service boundary anyway.

What ships at beta

Everything you need to run the four constants in production. No assembly required.

EngineWAL, SkipList, B+Tree & ValueLog
WASM RuntimeSandboxed Service Host, In-Process
HTTP ServerRouting, SSE, Streaming, Body Parsing
ZSX TemplatesCompiled Template Engine for HTML Output
WorkbenchBrowser UI to Deploy, Monitor, Configure
planctl CLIBuild & Deploy Services from your project
Native + WASM clientsTalk to the store from outside or inside
Backups + Metrics + GC + Export/ImportScheduled
Async ReplicationLog-based Async Replication
WAL Shipping to Network LocationOn WAL Rotation
ImportCSV/JSON/BSON Import
ExportCSV/JSON/BSON Export

Architectural Layers.

Everything that used to be a separate service is now an in-process module.

CLIENTBrowser or API ConsumerHTMX · Alpine AJAX · Datastar · JSON
↓ http / sse
HOSTⱣlanckHTTP listener · SSE Bus · Scheduler · WASM Runtime
↓ in-process
SERVICEyour-service.wasmHandlers · ZSX Templates · Business Logic
↓ direct call
STOREDocument Stores + IndexesValue Log · B+Tree · WAL · No Network Hop.
↓ render
RESPONSEHTML Fragment or JSONComposed in WASM, streamed to whatever asked

Pick any of the below patterns, Ᵽlanck Supports them all

A

Self-Contained System per domain

Recommended for new systems

One DB instance per bounded context. Each is a Self-Contained System - data, logic and ui in one process.

orders.wasm + storeproducts.wasm + storebilling.wasm + store
B

Monolith

Familiar mental model

One DB instance, one .wasm, handlers across every domain. The classic monolith, but compiled to a tiny sandboxed binary, deployed in one step, with zero network hops between layers.

app.wasm, all routesorders storeproducts storebilling store
C

Microservices

Drop-in for classic APIs

Same pattern as A, but handlers return JSON instead of HTML fragments. Everything still runs as WASM inside the database.

orders.wasm → JSONproducts.wasm → JSONbilling.wasm → JSON

The structural shift.

Forget tool inventories. The interesting comparison is how the layers of a typical web application stack are wired together and what that wiring costs.

Typical 3-tier app

  • DB, app server, and UI live in separate processes
  • Network round-trip on every query
  • ORM / query builder between code and tables
  • JSON API contract between backend and frontend
  • Schema changes coordinated across multiple deploys
  • Cross-service work via queues or out-of-band jobs

Ᵽlanck

  • Three layers in one process. One .wasm per bounded context.
  • Reads are direct memory calls, no socket, no serialization
  • Typed query builder against the embedded store, no ORM
  • Handlers return HTML fragments, no JSON layer to maintain
  • Schema, code, and templates ship in one .wasm
  • Cross-service events via the host SSE bus, in-process

Full reference: Getting Started

Planck · Beta · Built with Zig + WASM