Rasa
Blog

Rasa Data Scripts: A Practical Checkpoint

A small Data Scripts checkpoint showing file IO, JSON, EDN, HTTP, process input, runtime-Wasm parity, and browser fetch through admitted capabilities.

Rasa now has a compact Data Scripts checkpoint. It is intentionally ordinary: read a file, parse data, call HTTP, read process input, write output, and run the same source shape through native and runtime-Wasm products.

The point is not that this is a large application. The point is that it puts pressure on the useful parts of the language at once:

  • pure JSON and EDN helpers;
  • explicit file, network, and process capabilities;
  • capability reports before execution;
  • native ras and Wasmtime-backed ras-wasmtime execution;
  • browser exploration through dynamically configured provider modules.

The Source Shape

The canonical source lives at examples/data/script.ras.

(ns examples.data.script
  (:require [rasa.edn :as edn]
            [rasa.io :as io]
            [rasa.json :as json]
            [rasa.http :as http]
            [rasa.process :as process]))

The script reads examples/data/input.json, calls a local HTTP fixture through rasa.http/request, parses the response as JSON, reads args and environment, writes output JSON, and reads the written file back.

The source API is Rasa-shaped. The user code does not choose a Rust HTTP client, a Wasm provider, or browser fetch. It asks for the same capability contract:

(http/request {:method :get
              :url "http://127.0.0.1:48731/users.json"
              :headers {"accept" "application/json"}})

Target-specific providers implement that admitted request.

Running It

The easiest checkpoint starts a local fixture server, selects a free port, patches the example under target/, and runs native plus runtime-Wasm paths.

just data-scripts-e2e

The result shape is deliberately data, not a transcript:

{:status 200
 :local "local-file"
 :count 2
 :active true
 :names ["Ada" "Grace"]
 :args ["alpha" "beta"]
 :mode "native-or-wasm"
 :missing nil
 :write-status :written}

The browser-supported checkpoint builds the conformance report assets, loads the dynamic browser manifest, registers the rasa.http browser provider, and executes rasa.http/request through browser-style fetch.

just data-scripts-browser

Expected checkpoint output:

browser data scripts checkpoint ok
completed rasa.http/request

Capability Report

Before execution, Rasa can report what a script needs and whether the selected target admits it.

Capability plan: ok (native)
Capabilities:
- rasa.io/read-text available calls=1 effects=fs/read,may-suspend policy=fs/read boundary=copy-value
- rasa.io/write-text available calls=1 effects=fs/write,may-suspend policy=fs/write boundary=copy-value
- rasa.http/request available calls=1 effects=http/client,may-suspend policy=http/client boundary=copy-value
- rasa.process/args available calls=1 effects=env/read policy=env/read boundary=copy-value
- rasa.process/env available calls=1 effects=env/read policy=env/read boundary=copy-value

That is the important boundary. Source semantics stay stable. The selected runtime product decides which provider artifacts or browser modules are available and admitted.

Browser Scope

The browser checkpoint intentionally proves the browser-supported subset:

(require '[rasa.json :as json] '[rasa.http :as http])

(select-keys
  (http/request {:method :get
                :url "https://example.test/data.json"
                :headers {"accept" "application/json"}})
  [:status :body])

Browser HTTP uses browser fetch. Native and wasmtime HTTP use the provider stack selected for those targets. Rasa source code sees the same rasa.http/request contract either way.

This checkpoint does not claim browser filesystem access or browser process environment access. Those would need their own browser capability adapters and policy decisions.

What This Proves

Data Scripts proves a practical use path without weakening the boundary model:

  • pure data helpers are normal Rasa functions over Rasa values;
  • host effects cross explicit admitted capabilities;
  • capability reports explain the execution boundary before effects run;
  • native and runtime-Wasm share the same source-level contracts;
  • browser providers are loaded from dynamic configuration, not hard-coded page behavior.

The full local hardening command is:

just data-scripts