Alongside an investigation into the use of WebAssembly (Wasm) for cross-platform code deployment, I became aware that extensibility and vendor lock-in are concerns for adopters of low-code platforms. NodeRED was therefore used to prove the concept that Wasm can be used to overcome these limitations.
The language-agnostic, cross-platform nature of Wasm therefore makes it worthwhile for demonstrating how low-code platforms could be extended while avoiding vendor lock-in.
The appearance of the node within a flow.
Once downloaded, the Wasm file is stored on disk so that unnecessary network requests are avoided. To ensure the file can still be updated remotely, the ‘age’ parameter is used to trigger a fresh download when the file is too old.
As well as specifying the address and age of a Wasm file, an allowlist can use regular expressions to restrict where they can be fetched from. The URL is checked against syntactic rules and, depending on the ‘mode’ selected, it will be downloaded or denied. This is especially important for this NodeRED node as it’s possible to specify the address of the Wasm file at runtime.
URL Allowlist interface
Arguments and Input
The simplest way to use a Wasm module within NodeRED is to specify the name of the function to execute and the arguments to pass to it. This can be done through the editor or with messages.
If a Wasm module asks for user input, it can be specified through the editor or in a message. This will be passed to the function after it first executes.
Some modules may make use of environment variables, typically when a value remains constant. These can be configured in the editor.
Directories and Files
The underlying Wasmer library provides support for a virtual filesystem. By specifying paths for folders and content for files, these will be made available to the Wasm module. Paths and files generated by the module are also passed into the next message in the flow.
How to Install
Follow the instructions on the NodeRED website, or run ‘npm i @jackcarey/node-red-wasmer’ in your server directory.
How to Use
- Allowlist : ‘allowlist (regex)’ : An allowed list of URL regular expression patterns.
- URL: ‘url (string)’ : The address to fetch the WebAssembly file from.
- Function: ‘functionName (string)’ : The name of the function to run.
- Standard Input: ‘stdin (string)’ : Text to pass to the function after it first executes.
- Environment Variables: ‘env (JSON)’ : Environment variables that can be accessed withing the function.
- Arguments: ‘args (array[string])’ : Arguments to pass into the function separated by spaces.
- Directories: ‘dirs (JSON)’ : Virtual file paths made available to the module, and their contents.
- Age: ‘maxHours (number)’ : The maximum number of hours before attempting to re-fetch the ‘.wasm’ file.
Overriding Inputs: The following inputs can be overridden by passing them inside ‘msg.payload’: ‘url’, ‘functionName’, ‘stdin’, ‘args’, ‘dirs’.
Available inside ‘msg.wasmer’.
- Exit Code : ‘exitCode (number)’ : The exit code of the function that ran.
- Standard Input : ‘stdin (string)’ : The input buffer as a string.
- Standard Output : ‘stdout (string)’ : The console output of the function that ran.
- StdErr : ‘stderr (string)’ : Any error messages.
- Directories : ‘dirs (JSON)’ : The path and contents of each virtual file.
Check out the example ‘flows.json’.