EdgeChains: Declarative GenAI Chains in Jsonnet on the ts Branch

The Problem EdgeChains Targets: Prompt Drift and Prompt Explosion

The README frames the project's motivation as a management problem, not a modelling problem. It argues that prompts written for one model often need rewriting for another to reach the same goal, and that this multiplies the number of prompt variants a team has to keep track of. It also cites published work on how model behaviour changes over time, and calls the consequence prompt drift: production code rots even when nobody touched it. The stated remedy is to move prompts and chains out of library code and into declarative files. The README says that in EdgeChains your entire prompt and chain logic can sit in S3 or behind an API. That is the claim to evaluate: the value is in the separation, not in any particular retrieval trick. The audience is JavaScript and TypeScript teams already shipping GenAI features who have felt the pain of hunting a prompt string through several layers of abstraction. If your prompts are three lines long and never change, this framing will not match your situation.

How EdgeChains Works: Jsonnet Files, a Hono Server, and a WebAssembly Runtime

Two dependencies carry the architecture. The README states the project is built on honojs and jsonnet, describing them as built by Cloudflare and Google respectively, and it explicitly rejects inventing a custom DSL with a compilation step. Chains and prompts are authored in jsonnet, which the README says makes them diffable and versionable like any other configuration. On top of that, EdgeChains claims automatic parallelism across CPUs, GPUs and TPUs using a WebAssembly runtime, plus retry and backoff when some requests fail. The README also states that token cost tracking is built in, and gives one concrete figure: chain-of-thought style prompts consume at least three times as many output tokens as a normal prompt. Treat that number as a rationale for the measurement feature rather than as a benchmark of EdgeChains itself. The repository description adds that the library covers front-end, backend, APIs, prompt management and distributed computing, which is a wide surface for a project at this release cadence. The mechanism worth understanding is the data flow: a script file starts the server, jsonnet files describe the chain, and the runtime executes the steps. The README's own summary is that running a production-ready GenAI application takes one script file and one jsonnet file.

Getting the ChatWithPdf Example Running

The README documents one worked path. Clone the repository and enter it:

git clone https://github.com/arakoodev/EdgeChains/ cd EdgeChains

Then move into the example and install dependencies:

cd JS/edgechains/examples/chat-with-pdf/ npm install

Secrets go in secrets.jsonnet, not in an environment file. The README shows three locals and an object that exports them: SUPABASE_API_KEY, OPENAI_API_KEY and SUPABASE_URL, mapped to the keys supabase_api_key, supabase_url and openai_api_key. That is the whole configuration surface shown in the supplied material, and it tells you the example expects Supabase for storage and OpenAI for inference. The README's step four is headed "Database C" and is truncated in the material available here, so the database setup step cannot be reproduced from what I have. The README also points to JS/edgechains/examples as the place to start, with videos attached. Note the mismatch between the two npm packages advertised at the top of the README, @arakoodev/edgechains.js and @arakoodev/jsonnet, and the fact that the install instructions for the example are a plain npm install inside the example directory. Which package a fresh project should depend on is not resolved by the README text I have.

The ts Branch, the Release Cadence, and What That Means for Stability

The repository's default branch is ts, while the most recent release listed is 0.30.3, published on 2024-12-26. The two releases before it, 0.30.2 and 0.30.1, landed in December and November 2024. The last push to the repository is dated 2026-09-07, which is well after the newest tagged release. A reasonable reading is that active work is happening on the default branch and is not being cut into releases at the same pace. For anyone installing from npm, that gap matters: the README's claims about the architecture describe the project as it exists in the repository, and the published package may lag behind it. The README's production-readiness section leans on the maturity of honojs and jsonnet rather than on EdgeChains' own release history, which is a rhetorical move rather than evidence about this codebase. If you need a dependency with a predictable release train, this cadence is the thing to weigh first.

Licence and Maintenance Cost Under AGPL-3.0

EdgeChains is licensed AGPL-3.0. That is the most consequential fact in this review for commercial teams, and it is not a detail buried in a subdirectory. The AGPL extends copyleft to software offered over a network, so a service built on this library can trigger source-disclosure obligations that a permissive licence would not. I am not giving legal advice and cannot tell you how your deployment interacts with the licence; the point is that the licence question should be answered before an engineer spends a week on the example, not after. On maintenance cost, the material supports a narrower statement: the README's setup path is clone-and-run rather than a versioned dependency, and the example pins its configuration to Supabase and OpenAI through secrets.jsonnet. Upgrading means reconciling your jsonnet files with whatever the runtime expects, and the README does not describe a migration process or a compatibility policy between releases. Teams that treat prompt files as long-lived artefacts should plan for that reconciliation work.

Where EdgeChains Is the Wrong Tool

The design assumes your prompts are numerous enough and volatile enough to justify a configuration layer. If you call one model with one prompt from one endpoint, jsonnet is overhead you will pay for and never use. The README's own framing gives the second boundary: it argues that prompts hidden under layers of libraries are impossible to version, and the fix is to move them outside the code. That fix has a cost. A jsonnet file is a second language for your team, and the runtime has to resolve it, which means prompt changes are no longer plain JavaScript edits that your existing test setup already covers. There is also a deployment question the README raises but does not answer: it says prompt logic can live in S3 or behind an API. Remote prompt files are exactly the case where a network failure becomes a generation failure, and the README's fault-tolerance claim is described in terms of retry and backoff for requests, not for prompt retrieval. Finally, the truncated "Database C" step means the documented example cannot be completed end to end from the supplied material alone.

The Alternative: LangChain.js and Where the Two Diverge

LangChain.js is the obvious comparison for a JavaScript team, because it occupies the same layer: chains, prompt templates and model integrations in TypeScript. The difference in approach is where the chain definition lives. LangChain.js expresses chains as composed code objects, so a chain is a program you import and call. EdgeChains expresses chains as jsonnet data that the runtime reads. That single choice cascades. With LangChain.js, your editor, type checker and test runner understand the chain because it is code; with EdgeChains, the chain is configuration and your existing tooling does not see inside it. In the other direction, a jsonnet file is diffable in a pull request as plain text and can be moved to S3 or an API without a code deploy, which is the property EdgeChains is built around and which code-defined chains do not have. Neither is strictly better. If you want the chain to be a typed object your IDE can follow, LangChain.js is the more natural fit. If you want the chain to be an artefact you can version, diff and relocate independently of your application build, EdgeChains is making a coherent bet.

Who Should Adopt EdgeChains, and What to Verify First

The project suits a team that already runs JavaScript services, has accumulated enough prompt variants that versioning has become a real chore, and can live with AGPL-3.0. It does not suit a team that needs a permissive licence, a small single-prompt integration, or a dependency with a regular release cadence. The verification list is short and specific. First, read the ts branch rather than the README, because the default branch is where the last push landed and the README's step four is incomplete. Second, decide which npm package you are depending on, since the README advertises @arakoodev/edgechains.js and @arakoodev/jsonnet but the example installs with a bare npm install. Third, decide whether your jsonnet files will be read from disk or fetched from S3 or an API, since the README presents the remote option as a feature and does not describe what happens when that fetch fails. Fourth, run the chat-with-pdf example with your own secrets.jsonnet before designing anything around the library. That example is the only end-to-end path the supplied material documents.

Editorial conclusion

Adopt EdgeChains if you already run JavaScript services, you want prompt and chain definitions to live in versioned jsonnet files, and you can accept AGPL-3.0. Do not adopt it if you need a permissive licence, if your team has no appetite for jsonnet, or if you need a stable published API surface: the most recent release listed is 0.30.3 from December 2024, while the default branch is ts. Before installing anything, read the ts branch rather than the README, confirm which npm package you are actually expected to depend on, and check whether the jsonnet files are loaded from disk or from a remote URL in the deployment you plan to run.

Official sources

1. arakoodev/EdgeChains on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases