The Problem

Building AI‑driven applications today requires stitching together LLM calls, database queries, human‑in‑the‑loop steps, and various messaging APIs. Each integration is a separate SDK, custom webhook, or ad‑hoc state store, which makes the overall system fragile and hard to reason about.

What This Does

Weft defines a domain‑specific language that treats LLMs, humans, HTTP endpoints, and infrastructure as first‑class node types. A compiler validates connections and types, then produces a durable execution graph that runs on Restate.

Key source locations:

  • The language core lives in crates/weft-core/src/lib.rs and the API server in crates/weft-api/src/main.rs.
  • Node catalog definitions (e.g., Discord, WhatsApp, Postgres) are under catalog/communication/… and catalog/storage/….
  • The web UI for authoring graphs is the Svelte dashboard in dashboard/src/lib/ai/… and dashboard/src/lib/types/index.ts.

How It Is Wired

Execution begins at the Svelte server hook dashboard/src/hooks.server.ts (line 128). This handler invokes initDb (defined in dashboard/src/lib/server/db.ts) to obtain a PostgreSQL pool, then routes requests to the API layer (crates/weft-api).

The API entry point (crates/weft-api/src/main.rs) starts an HTTP server that forwards incoming REST calls to the compiler (crates/weft-core). The core parses Weft source (dashboard/src/lib/ai/weft-parser.ts) using functions such as parseWeftType (called 18 times) and isWeftTypeCompatible (7 times). These parsers feed the NodeDefinition bindings (crates/weft-core/bindings/NodeDefinition) which are the most imported module (Ca = 1, Ce = 6, instability 0.86).

After validation, the runtime creates a Restate workflow; the only outward effect is a database write (initDb → pool.query) and, for side‑car services, container builds defined in catalog/communication/:whatsapp/bridge/sidecar/Dockerfile. The Dockerfile builds a Node 22‑alpine image that runs catalog/communication/:whatsapp/bridge/sidecar/src/index.js. No file currently invokes filesystem‑level cryptography beyond dashboard/src/lib/server/crypto.ts, which provides encrypt/decrypt utilities used only by the dashboard.

The internal call graph shows a hub at emit (called from 65 locations) and a dense validation path: validate → isInputConnected (154 calls) and validate → getConnectedNodeType (44 calls). These functions have the widest blast radius; changes here propagate to most node‑type handling code.

How To Use It

# Clone the repo (exact URL required)
git clone https://github.com/moses-y/weft
cd weft

# Create environment file
cp .env.example .env
# Edit .env to supply OpenRouter, Tavily, etc. keys (no defaults in repo)

# Start all services (dev.sh orchestrates Docker + Rust + Node)
./dev.sh server    # launches PostgreSQL, Restate, API server
./dev.sh dashboard # runs the Svelte UI on http://localhost:5173

The dashboard UI lets you author Weft programs; the backend persists them in PostgreSQL and executes via Restate. No additional build steps are required because dev.sh invokes pnpm install and cargo build automatically.

Real‑World Use

A product team could model a customer‑support flow: an incoming email node (catalog/communication/:email/lib.rs) triggers an LLM summarizer node, passes the summary to a human‑approval node, and on approval writes the result to a Postgres node (catalog/storage/:postgres/database/sidecar). The entire flow is expressed in a few Weft lines, type‑checked at compile time, and survives days‑long human delays because Restate persists the workflow state.

Code Health & Issues

Measured findings

  • HIGH – Oversized files – dashboard/src/lib/ai/weft-editor.ts, dashboard/src/lib/ai/weft-parser.ts, crates/weft-api/src/routes.rs (> 1 200 lines each).
  • HIGH – Deep nesting – Same editor/parser files and catalog/ai/generative/:llm/inference/backend.rs (indentation depth 11).
  • HIGH – Duplicated code – Repeated 6‑line blocks across 224 files (e.g., config handling in several backend.rs files).
  • MEDIUM – High branching density – Editor and parser files (468 branch points).

Code‑health audit

  • HIGH – No CI workflow; 367 source files lack automated build/test gating.
  • HIGH – Dockerfile for WhatsApp bridge (catalog/communication/:whatsapp/bridge/sidecar/Dockerfile) has no build validation.
  • MEDIUM – No Dependabot/Renovate configuration for 9 manifest files.
  • MEDIUM – Base image node:22-alpine is not pinned by digest.
  • MEDIUM – Dockerfile runs as root; no non‑root USER declared.
  • LOW – Repository missing conventional files (.editorconfig, .gitattributes, formatter config).

All other hygiene checks (tests present, licence, lockfile, no committed secrets) pass.

The Bottom Line

Weft provides a coherent, type‑safe language for stitching AI components together and includes a functional UI and Docker side‑cars. The core ideas are solid, but the codebase suffers from large, deeply nested files, duplicated logic, and a lack of CI/CD automation, which raises maintenance risk. It is suitable for teams willing to invest in refactoring and adding proper CI pipelines; early adopters should treat it as a foundation rather than a production‑ready platform.