Authoring tools beyond AssemblyScript

Subgraphs have been written in AssemblyScript since the beginning. Three projects argue that the language, and in one case the file format, was never the interesting part.

Checked against Graph Horizon (2025-12-11)

Last read 2026-08-30 Due again 2026-11-30

Every protocol claim below was read at these sources on 2026-08-30. Where they disagree with each other, the entry says so.

A subgraph is three files: a manifest, a schema and mappings. The mappings have conventionally been AssemblyScript, a TypeScript-like language compiled to WebAssembly.

The protocol never required that. It requires deterministic WebAssembly. AssemblyScript is one way to produce it, and three projects take the constraint at its word.

graphite

graphite is a Rust SDK for authoring subgraphs, producing WASM that is ABI-compatible with what graph-node already expects. No change to indexers, no change to the protocol: the output is a subgraph like any other.

The argument is straightforwardly about tooling. Rust brings a type system that has opinions, a mature package ecosystem, and error handling that does not rely on the author remembering. Against that, your team has to write Rust, which is the same staffing cost Substreams carries.

redstart

redstart goes further and questions the file layout rather than the language. One source file describes the schema, the manifest and the handlers together, and transpiles out to the three files graph-node wants.

The observation behind it is that the three-file split is an implementation detail that leaked into the authoring experience. An entity, the event that produces it and the field it populates are one thought, and they currently live in three files that must be kept manually in agreement. Anyone who has renamed a field and then hunted the schema, the mapping and the codegen output for the other two mentions knows the shape of the problem.

There is a dispatch on the reasoning, which is worth reading for the argument rather than the announcement.

liminal

liminal is the most speculative of the three: a polyglot, capability-isolated WASIp2 component runtime for streaming indexing pipelines.

The idea is that if the real requirement is deterministic WebAssembly components, then the runtime should accept components from any language that compiles to WASIp2, with capabilities granted explicitly rather than assumed. Determinism then comes from what the component is allowed to do rather than from which language it was written in.

Read it as a research direction rather than something to build a product on this quarter.

What to actually use

For most people, most of the time: the official tooling, in AssemblyScript, per the developer collection. It is what the documentation covers, what indexers expect, and what somebody else on your team will recognise.

Reach for an alternative when you have a specific reason. Your team is a Rust shop and the subgraph is substantial: graphite. You are maintaining many subgraphs and the three-file drift is costing you real time: look at redstart. You are researching what indexing could look like: liminal.