DEV Community: alabulei1

Running JavaScript in WebAssembly with WasmEdge

alabulei1 — Thu, 23 Sep 2021 16:38:46 +0000

WebAssembly started as a “JavaScript alternative for browsers”. The idea is to run high-performance applications compiled from languages like C/C++ or Rust safely in browsers. In the browser, WebAssembly runs side by side with JavaScript.

Figure 1. WebAssembly and JavaScript in the browser.

As WebAssembly is increasingly used in the cloud, it is now a universal runtime for cloud-native applications. Compared with Docker-like application containers, WebAssembly runtimes achieve higher performance with lower resource consumption. The common uses cases for WebAssembly in the cloud include the following.

Runtime for serverless function-as-a-service (FaaS)
Embedding user-defined functions into SaaS apps or databases
Runtime for sidecar applications in a service mesh
Programmable plug-ins for web proxies
Sandbox runtimes for edge devices including software-defined vehicles and smart factories

However, in those cloud-native use cases, developers often want to use JavaScript to write business applications. That means we must now support JavaScript in WebAssembly. Furthermore, we should support calling C/C++ or Rust functions from JavaScript in a WebAssembly runtime to take advantage of WebAssembly’s computational efficiency. The WasmEdge WebAssembly runtime allows you to do exactly that.

Figure 2. WebAssembly and JavaScript in the cloud.

WasmEdge

WasmEdge is a leading cloud-native WebAssembly runtime hosted by the CNCF (Cloud Native Computing Foundation) / Linux Foundation. It is the fastest WebAssembly runtime in the market today. WasmEdge supports all standard WebAssembly extensions as well as proprietary extensions for Tensorflow inference, KV store, and image processing, etc. Its compiler toolchain supports not only WebAssembly languages such as C/C++, Rust, Swift, Kotlin, and AssemblyScript but also regular JavaScript.

A WasmEdge application can be embedded into a C program, a Go program, a Rust program, a JavaScript program, or the operating system’s CLI. The runtime can be managed by Docker tools (eg CRI-O), orchestration tools (eg K8s), serverless platforms (eg Vercel, Netlify, AWS Lambda, Tencent SCF), and data streaming frameworks (eg YoMo and Zenoh).

Now, you can run JavaScript programs in WasmEdge powered serverless functions, microservices, and AIoT applications! It not only runs plain JavaScript programs but also allows developers to use Rust and C/C++ to create new JavaScript APIs within the safety sandbox of WebAssembly.

Building a JavaScript engine in WasmEdge

First, let’s build a WebAssmbly-based JavaScript interpreter program for WasmEdge. It is based on QuickJS with WasmEdge extensions, such as network sockets and Tensorflow inference, incorporated into the interpreter as JavaScript APIs. You will need to install Rust to build the interpreter.

If you just want to use the interpreter to run JavaScript programs, you can skip this section. Make sure you have installed Rust and WasmEdge.

Fork or clone the wasmegde-quickjs Github repository to get started.

$ git clone https://github.com/second-state/wasmedge-quickjs

Following the instructions from that repo, you will be able to build a JavaScript interpreter for WasmEdge.

$ rustup target add wasm32-wasi
$ cargo build --target wasm32-wasi --release

The WebAssembly-based JavaScript interpreter program is located in the build target directory. You can now try a simple “hello world” JavaScript program (example_js/hello.js), which prints out the command line arguments to the console.

args = args.slice(1)
print(“Hello”,…args)

Run the hello.js file in WasmEdge’s QuickJS runtime as follows. Note, the --dir .:. on the command line is to give wasmedge permission to read the local directory in the file system for the hello.js file.

$ wasmedge --dir .:. target/wasm32-wasi/release/quickjs-rs-wasi.wasm example_js/hello.js WasmEdge Runtime
Hello WasmEdge Runtime

Next, let’s try a few more advanced JavaScript programs.

A JavaScript networking example

The interpreter supports the WasmEdge networking socket extension so that your JavaScript can make HTTP connections to the Internet. Here is an example of JavaScript.

let r = GET("http://18.235.124.214/get?a=123",{"a":"b","c":[1,2,3]})
print(r.status)

let headers = r.headers
print(JSON.stringify(headers))let body = r.body;
let body_str = new Uint8Array(body)
print(String.fromCharCode.apply(null,body_str))

To run the JavaScript in the WasmEdge runtime, you can do this on the CLI.

$ wasmedge --dir .:. target/wasm32-wasi/release/quickjs-rs-wasi.wasm example_js/http_demo.js

You should now see the HTTP GET result printed on the console.

A JavaScript Tensorflow inference example

The interpreter supports the WasmEdge Tensorflow lite inference extension so that your JavaScript can run an ImageNet model for image classification. Here is an example of JavaScript.

import {TensorflowLiteSession} from 'tensorflow_lite'
import {Image} from 'image'let img = new Image('./example_js/tensorflow_lite_demo/food.jpg')
let img_rgb = img.to_rgb().resize(192,192)
let rgb_pix = img_rgb.pixels()let session = new TensorflowLiteSession('./example_js/tensorflow_lite_demo/lite-model_aiy_vision_classifier_food_V1_1.tflite')
session.add_input('input',rgb_pix)
session.run()
let output = session.get_output('MobilenetV1/Predictions/Softmax');
let output_view = new Uint8Array(output)
let max = 0;
let max_idx = 0;
for (var i in output_view){
    let v = output_view[i]
    if(v>max){
        max = v;
        max_idx = i;
    }
}
print(max,max_idx)

To run the JavaScript in the WasmEdge runtime, you can do the following on the CLI to re-build the QuickJS engine with Tensorflow and then run the JavaScript program with Tensorflow API.

$ cargo build --target wasm32-wasi --release --features=tensorflow
... ...
$ wasmedge-tensorflow-lite --dir .:. target/wasm32-wasi/release/quickjs-rs-wasi.wasm example_js/tensorflow_lite_demo/main.js
label:
Hot dog
confidence:
0.8941176470588236

Note:

The --features=tensorflow compiler flag builds a version of the QuickJS engine with WasmEdge Tensorflow extensions.
The wasmedge-tensorflow-lite program is part of the WasmEdge package. It is the WasmEdge runtime with the Tensorflow extension built in.

You should now see the name of the food item recognized by the TensorFlow lite ImageNet model.

Make it faster

The above Tensorflow inference example takes 1–2 seconds to run. It is acceptable in web application scenarios but could be improved. Recall that WasmEdge is the fastest WebAssembly runtime today due to its AOT (Ahead-of-time compiler) optimization. WasmEdge provides a wasmedgec utility to compile the wasm file to a native so shared library. You can use wasmedge to run the so file instead of wasm file to get much faster performance.

The following example uses the extended versions to wasmedge and wasmedgec to support the WasmEdge Tensorflow extension.

$ wasmedgec-tensorflow target/wasm32-wasi/release/quickjs-rs-wasi.wasm quickjs-rs-wasi.so
$ wasmedge-tensorflow-lite --dir .:. quickjs-rs-wasi.so example_js/tensorflow_lite_demo/main.js
label:
Hot dog
confidence:
0.8941176470588236

You can see that the image classification task can be completed within 0.1s. It is at least 10x improvement!

The so shared library is not portable across machines and OSes. You should run wasmedgec and wasmedgec-tensorflow on the machine you deploy and run the application.

A note on QuickJS

Now, the choice of QuickJS as our JavaScript engine might raise the question of performance. Isn’t QuickJS a lot slower than v8 due to a lack of JIT support? Yes, but …

First of all, QuickJS is a lot smaller than v8. In fact, it only takes 1/40 (or 2.5%) of the runtime resources v8 consumes. You can run a lot more QuickJS functions than v8 functions on a single physical machine.

Second, for most business logic applications, raw performance is not critical. The application may have computationally intensive tasks, such as AI inference on the fly. WasmEdge allows the QuickJS applications to drop to high-performance WebAssembly for these tasks while it is not so easy with v8 to add such extensions modules.

Third, it is known that many JavaScript security issues arise from JIT. Maybe turning off JIT in the cloud-native environment is not such a bad idea!

What’s next?

The examples demonstrate how to use the quickjs-rs-wasi.wasm JavaScript engine in WasmEdge. Besides using the CLI, you could use Docker / Kubernetes tools to start the WebAssembly application or to embed the application into your own applications or frameworks as we discussed earlier in this article.

In the next two articles, I will focus on using JavaScript together with Rust to make the most out of both languages.

How to incorporate simple JavaScript snippets into a high-performance Rust app in WasmEdge.
How to make a high-performance native function available as a JavaScript API in WasmEdge.

JavaScript in cloud-native WebAssembly is still an emerging area in the next generation of cloud and edge computing infrastructure. We are just getting started! If you are interested, join us in the WasmEdge project (or tell us what you want by raising feature request issues).

Rust and WebAssembly Serverless functions in Vercel

alabulei1 — Mon, 23 Aug 2021 15:07:12 +0000

Vercel is a leading platform for developing and hosting Jamstack applications. Unlike traditional web apps, where the UI is dynamically generated at runtime from a server, a Jamstack application consists of a static UI (in HTML and JavaScript) and a set of serverless functions to support dynamic UI elements via JavaScript.

There are many benefits to the Jamstack approach. But perhaps one of the most significant benefits is performance. Since the UI is no longer generated at runtime from a central server, there is much less load on the server and we can now deploy the UI via edge networks such as CDNs.

However, the edge CDN only solves the problem of distributing the static UI files. The backend serverless functions could still be slow. In fact, popular serverless platforms have well-known performance issues, such as slow cold start, especially for interactive applications. That's where WebAssembly could help.

With WasmEdge, a cloud-native WebAssembly runtime hosted by the CNCF, developers can write high-performance serverless functions deployed on the public cloud or on edge computing nodes. In this article, we will explore how to use WasmEdge functions, written in Rust, to power a Vercel application backend.

Why WebAssembly in Vercel Serverless?

The Vercel platform already has a very easy-to-use serverless framework for deploying functions hosted in Vercel. As we discussed above, the reason to use WebAssembly, and WasmEdge, is to further improve performance. High-performance functions written in C/C++, Rust, and Swift can be easily compiled into WebAssembly. Those WebAssembly functions are much faster than JavaScript or Python commonly used in serverless functions.

However, if raw performance is the only goal, why not just compile those functions to machine native executables (Native Client or NaCl)? Vercel already runs these functions safely in application containers like Docker or Firecracker.

Our vision for the future is to run WebAssembly as an alternative lightweight runtime side-by-side with Docker and other containers in cloud native infrastructure. WebAssembly offers much higher performance and consumes much less resources than Docker-like containers or Firecracker-like microVMs. But for now, Vercel only supports running WebAssembly inside other containers.

Running WebAssembly functions inside Docker-like containers offer advantages over running NaCl programs directly in Docker.

For starters, WebAssembly provides fine-grained runtime isolation for individual functions. A microservice could have multiple functions and support services running inside a Docker-like container. WebAssembly can make the microservice more secure and more stable.

Second, the WebAssembly bytecode is portable. Developers only need to build it once and do not need to worry about changes or updates to the underlying Vercel serverless container (OS and hardware). It also allows developers to reuse the same WebAssembly functions in other cloud environments.

Third, WebAssembly apps are easy to deploy and manage. They have much less platform dependencies and complexities compared with NaCl dynamic libraries and executables.

Finally, the WasmEdge Tensorflow API provides the most ergonomic way to execute Tensorflow models in the Rust programming language. WasmEdge installs the correct combination of Tensorflow dependency libraries, and provides a unified API for developers.

Enough with the concepts and explanations. Without further ado, let's jump into the example apps!

Prerequisite

Since our demo WebAssembly functions are written in Rust, you will need a Rust compiler. Make sure that you install the wasm32-wasi compiler target as follows, in order to generate WebAssembly bytecode.

$ rustup target add wasm32-wasi

The demo application front end is written in Next.js, and deployed on Vercel. We will assume that you already have the basic knowledge of how to work with Vercel.

Example 1: Image processing

Our first demo application allows users to upload an image and then invoke a serverless function to turn it into black and white. A live demo deployed on Vercel is available.

Fork the demo application’s GitHub repo to get started. To deploy the application on Vercel, just import the Github repo from Vercel for Github web page.

This repo is a standard Next.js application for the Vercel platform. The backend serverless function is in the api/functions/image_grayscale folder. The src/main.rs file contains the Rust program’s source code. The Rust program reads image data from the STDIN, and then outputs the black-white image to the STDOUT.

use hex;
use std::io::{self, Read};
use image::{ImageOutputFormat, ImageFormat};

fn main() {
  let mut buf = Vec::new();
  io::stdin().read_to_end(&mut buf).unwrap();

  let image_format_detected: ImageFormat = image::guess_format(&buf).unwrap();
  let img = image::load_from_memory(&buf).unwrap();
  let filtered = img.grayscale();
  let mut buf = vec![];
  match image_format_detected {
    ImageFormat::Gif => {
        filtered.write_to(&mut buf, ImageOutputFormat::Gif).unwrap();
    },
    _ => {
        filtered.write_to(&mut buf, ImageOutputFormat::Png).unwrap();
    },
  };
  io::stdout().write_all(&buf).unwrap();
  io::stdout().flush().unwrap();
}

You can use Rust’s cargo tool to build the Rust program into WebAssembly bytecode or native code.

$ cd api/functions/image-grayscale/
$ cargo build --release --target wasm32-wasi

Copy the build artifacts to the api folder.

$ cp target/wasm32-wasi/release/grayscale.wasm ../../

Vercel runs api/pre.sh upon setting up the serverless environment. It installs the WasmEdge runtime, and then compiles each WebAssembly bytecode program into a native so library for faster execution.

The api/hello.js file conforms Vercel serverless specification. It loads the WasmEdge runtime, starts the compiled WebAssembly program in WasmEdge, and passes the uploaded image data via STDIN. Notice api/hello.js runs the compiled grayscale.so file generated by api/pre.sh for better performance.

const fs = require('fs');
const { spawn } = require('child_process');
const path = require('path');

module.exports = (req, res) => {
  const wasmedge = spawn(
      path.join(__dirname, 'wasmedge'), 
      [path.join(__dirname, 'grayscale.so')]);

  let d = [];
  wasmedge.stdout.on('data', (data) => {
    d.push(data);
  });

  wasmedge.on('close', (code) => {
    let buf = Buffer.concat(d);

    res.setHeader('Content-Type', req.headers['image-type']);
    res.send(buf);
  });

  wasmedge.stdin.write(req.body);
  wasmedge.stdin.end('');
}

That's it. Deploy the repo to Vercel and you now have a Vercel Jamstack app with a high-performance Rust and WebAssembly based serverless backend.

Example 2: AI inference

The second demo application allows users to upload an image and then invoke a serverless function to classify the main subject on the image.

It is in the same GitHub repo as the previous example but in the tensorflow branch. Note: when you import this GitHub repo on the Vercel website, it will create a preview URL for each branch. The tensorflow branch would have its own deployment URL.

The backend serverless function for image classification is in the api/functions/image-classification folder in the tensorflow branch. The src/main.rs file contains the Rust program’s source code. The Rust program reads image data from the STDIN, and then outputs the text output to the STDOUT. It utilizes the WasmEdge Tensorflow API to run the AI inference.

pub fn main() {
    // Step 1: Load the TFLite model
    let model_data: &[u8] = include_bytes!("models/mobilenet_v1_1.0_224/mobilenet_v1_1.0_224_quant.tflite");
    let labels = include_str!("models/mobilenet_v1_1.0_224/labels_mobilenet_quant_v1_224.txt");

    // Step 2: Read image from STDIN
    let mut buf = Vec::new();
    io::stdin().read_to_end(&mut buf).unwrap();

    // Step 3: Resize the input image for the tensorflow model
    let flat_img = wasmedge_tensorflow_interface::load_jpg_image_to_rgb8(&buf, 224, 224);

    // Step 4: AI inference
    let mut session = wasmedge_tensorflow_interface::Session::new(&model_data, wasmedge_tensorflow_interface::ModelType::TensorFlowLite);
    session.add_input("input", &flat_img, &[1, 224, 224, 3])
           .run();
    let res_vec: Vec<u8> = session.get_output("MobilenetV1/Predictions/Reshape_1");

    // Step 5: Find the food label that responds to the highest probability in res_vec
    // ... ...
    let mut label_lines = labels.lines();
    for _i in 0..max_index {
      label_lines.next();
    }

    // Step 6: Generate the output text
    let class_name = label_lines.next().unwrap().to_string();
    if max_value > 50 {
      println!("It {} a <a href='https://www.google.com/search?q={}'>{}</a> in the picture", confidence.to_string(), class_name, class_name);
    } else {
      println!("It does not appears to be any food item in the picture.");
    }
}

You can use the cargo tool to build the Rust program into WebAssembly bytecode or native code.

$ cd api/functions/image-classification/
$ cargo build --release --target wasm32-wasi

Copy the build artifacts to the api folder.

$ cp target/wasm32-wasi/release/classify.wasm ../../

Again, the api/pre.sh script installs WasmEdge runtime and its Tensorflow dependencies in this application. It also compiles the classify.wasm bytecode program to the classify.so native shared library at the time of deployment.

The api/hello.js file conforms Vercel serverless specification. It loads the WasmEdge runtime, starts the compiled WebAssembly program in WasmEdge, and passes the uploaded image data via STDIN. Notice api/hello.js runs the compiled classify.so file generated by api/pre.sh for better performance.

const fs = require('fs');
const { spawn } = require('child_process');
const path = require('path');

module.exports = (req, res) => {
  const wasmedge = spawn(
    path.join(__dirname, 'wasmedge-tensorflow-lite'),
    [path.join(__dirname, 'classify.so')],
    {env: {'LD_LIBRARY_PATH': __dirname}}
  );

  let d = [];
  wasmedge.stdout.on('data', (data) => {
    d.push(data);
  });

  wasmedge.on('close', (code) => {
    res.setHeader('Content-Type', `text/plain`);
    res.send(d.join(''));
  });

  wasmedge.stdin.write(req.body);
  wasmedge.stdin.end('');
}

You can now deploy your forked repo to Vercel and have a web app for subject classification.

What's next

Running WasmEdge from Vercel’s current serverless container is an easy way to add high-performance functions to Vercel applications. If you have created an interesting Vercel function using WasmEdge, pleaselet us know and we will send you a WasmEdge SWAG!

Going forward an even better approach is to use WasmEdge as the container itself. There will be no Docker and no Node.JS to bootstrap WasmEdge. This way, we can reach much higher efficiency for running serverless functions. WasmEdge is already compatible with Docker tools. If you are interested in joining WasmEdge and CNCF for this exciting work, let us know!

😎 Manage WebAssembly Apps in WasmEdge Using Docker Tools

alabulei1 — Tue, 29 Jun 2021 11:55:31 +0000

Developers can leverage Docker tools such as the DockerHub and CRI-O to deploy, manage, and run lightweight WebAssembly applications in WasmEdge. WasmEdge, an advanced WebAssembly runtime hosted by the CNCF (Cloud Native Computing Foundation), is an execution sandbox for Edge Computing applications.

While WebAssembly was initially invented as a runtime for browser applications, its lightweight and high-performance sandbox design has made it an appealing choice as a general-purpose application container.

If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. — Solomon Hykes, co-founder of Docker

Compared with Docker, WebAssembly could be 100x faster at startup, have a much smaller memory and disk footprint, and have a better-defined safety sandbox. However, the trade-off is that WebAssembly requires its own language SDKs, and compiler toolchains, making it a more constrained developer environment than Docker. WebAssembly is increasingly used in Edge Computing scenarios where it is difficult to deploy Docker or when the application performance is vital.

One of the great advantages of Docker is its rich ecosystem of tools. At WasmEdge, we would like to bring Docker-like tooling to our developers. To accomplish that, we created an alternative runner for CRI-O, called runw, to load and run WebAssembly bytecode programs as if they are Docker image files.

Install an WebAssembly runner in CRI-O

In order to support WebAssembly in CRI-O, you just need to download the runw binary release and install it into your CRI-O.

Since the runw binary already includes WasmEdge, there is no need to install WasmEdge or any other WebAssembly VM separately.

First, make sure that you are on Ubuntu 20.04 with LLVM-10 installed. If you are on a different platform, please refer to the project documentation on how to build runw for your OS.

sudo apt install -y llvm-10-dev liblld-10-dev

Also make sure that you have cri-o, crictl, containernetworking-plugins, and buildah or docker installed.

Next, download the runw binary build.

wget https://github.com/second-state/runw/releases/download/0.1.0/runw

Now, you can install runw into CRI-O as an alternative runtime for WebAssembly.

# Get the wasm-pause utility
sudo crictl pull docker.io/beststeve/wasm-pause

# Install runw into cri-o
sudo cp -v runw /usr/lib/cri-o-runc/sbin/runw
sudo chmod +x /usr/lib/cri-o-runc/sbin/runw
sudo sed -i -e 's@default_runtime = "runc"@default_runtime = "runw"@' /etc/crio/crio.conf
sudo sed -i -e 's@pause_image = "k8s.gcr.io/pause:3.2"@pause_image = "docker.io/beststeve/wasm-pause"@' /etc/crio/crio.conf
sudo sed -i -e 's@pause_command = "/pause"@pause_command = "pause.wasm"@' /etc/crio/crio.conf
sudo tee -a /etc/crio/crio.conf.d/01-crio-runc.conf <<EOF
[crio.runtime.runtimes.runw]
runtime_path = "/usr/lib/cri-o-runc/sbin/runw"
runtime_type = "oci"
runtime_root = "/run/runw"
EOF

Finally, restart cri-o for the new WebAssembly runner to take effect.

sudo systemctl restart crio

Build a Wasm application from Rust

The sample Wasm application is written in Rust. To make it work, make sure that you have Rust and the rustwasmc toolchains installed.

You only need Rust compiler and rustwasmc to build Rust source into a wasm bytecode file. If you already have a wasm bytecode program, and just want to run it with cri-o, you can simply skip this section.

The application source code is just a main.rs function. It is here. The application demonstrates how to access the file system and other operating system resources from WasmEdge using the standard Rust API.

fn main() {
  println!("Random number: {}", get_random_i32());
  println!("Random bytes: {:?}", get_random_bytes());
  println!("{}", echo("This is from a main function"));
  print_env();
  create_file("/tmp.txt", "This is in a file");
  println!("File content is {}", read_file("/tmp.txt"));
  del_file("/tmp.txt");
}

pub fn get_random_i32() -> i32 {
  let x: i32 = random();
  return x;
}

pub fn get_random_bytes() -> Vec<u8> {
  let mut rng = thread_rng();
  let mut arr = [0u8; 128];
  rng.fill(&mut arr[..]);
  return arr.to_vec();
}

pub fn echo(content: &str) -> String {
  println!("Printed from wasi: {}", content);
  return content.to_string();
}

pub fn print_env() {
  println!("The env vars are as follows.");
  for (key, value) in env::vars() {
    println!("{}: {}", key, value);
  }

  println!("The args are as follows.");
  for argument in env::args() {
    println!("{}", argument);
  }
}

pub fn create_file(path: &str, content: &str) {
  let mut output = File::create(path).unwrap();
  output.write_all(content.as_bytes()).unwrap();
}

pub fn read_file(path: &str) -> String {
  let mut f = File::open(path).unwrap();
  let mut s = String::new();
  match f.read_to_string(&mut s) {
    Ok(_) => s,
    Err(e) => e.to_string(),
  }
}

pub fn del_file(path: &str) {
  fs::remove_file(path).expect("Unable to delete");
}

You can build the application into a wasm bytecode file as follows.

rustwasmc build

The outcome wasm bytecode file is available here.

Build and publish a Docker Hub image for the Wasm app

You can now publish the entire wasm bytecode file into Docker hub as if it is a Docker image.

First, create a Dockerfile in the pkg/ directory as follows.

FROM scratch
ADD wasi_example_main.wasm .
CMD ["wasi_example_main.wasm"]

Create an image and publish it to Docker hub!

sudo buildah bud -f Dockerfile -t wasm-wasi-example
sudo buildah push wasm-wasi-example docker://registry.example.com/repository:tag

# Example: the following command publishes the wasm image to the public Docker hub under user account "hydai"
sudo buildah push wasm-wasi-example docker://docker.io/hydai/wasm-wasi-example:latest

Now, you can use Docker tools, such as the crictl, to pull the publish wasm file as an image. Below is an example for the wasm file image we published.

sudo crictl pull docker.io/hydai/wasm-wasi-example

Start the Wasm app using CRI-O

To start and run the wasm file, you will need to create two configuration files for CRI-O. Create a container_wasi.json file as follows. It tells the CRI-O runtime where to pull the wasm file image from the Docker repository.

{
  "metadata": {
    "name": "podsandbox1-wasm-wasi"
  },
  "image": {
    "image": "hydai/wasm-wasi-example:latest"
  },
  "args": [
    "wasi_example_main.wasm", "50000000"
  ],
  "working_dir": "/",
  "envs": [],
  "labels": {
    "tier": "backend"
  },
  "annotations": {
    "pod": "podsandbox1"
  },
  "log_path": "",
  "stdin": false,
  "stdin_once": false,
  "tty": false,
  "linux": {
    "resources": {
      "memory_limit_in_bytes": 209715200,
      "cpu_period": 10000,
      "cpu_quota": 20000,
      "cpu_shares": 512,
      "oom_score_adj": 30,
      "cpuset_cpus": "0",
      "cpuset_mems": "0"
    },
    "security_context": {
      "namespace_options": {
        "pid": 1
      },
      "readonly_rootfs": false,
      "capabilities": {
        "add_capabilities": [
          "sys_admin"
        ]
      }
    }
  }
}

Next, create a sandbox_config.json file as follows. It defines the sandbox environment to run the wasm application.

{
  "metadata": {
    "name": "podsandbox12",
    "uid": "redhat-test-crio",
    "namespace": "redhat.test.crio",
    "attempt": 1
  },
  "hostname": "crictl_host",
  "log_directory": "",
  "dns_config": {
    "searches": [
      "8.8.8.8"
    ]
  },
  "port_mappings": [],
  "resources": {
    "cpu": {
      "limits": 3,
      "requests": 2
    },
    "memory": {
      "limits": 50000000,
      "requests": 2000000
    }
  },
  "labels": {
    "group": "test"
  },
  "annotations": {
    "owner": "hmeng",
    "security.alpha.kubernetes.io/seccomp/pod": "unconfined"
  },
  "linux": {
    "cgroup_parent": "pod_123-456.slice",
    "security_context": {
      "namespace_options": {
        "network": 0,
        "pid": 1,
        "ipc": 0
      },
      "selinux_options": {
        "user": "system_u",
        "role": "system_r",
        "type": "svirt_lxc_net_t",
        "level": "s0:c4,c5"
      }
    }
  }
}

Now you can create a CRI-O pod as follows.

# Create the POD. Output will be different from example.
sudo crictl runp sandbox_config.json
7992e75df00cc1cf4bff8bff660718139e3ad973c7180baceb9c84d074b516a4

# Set a helper variable for later use.
POD_ID=7992e75df00cc1cf4bff8bff660718139e3ad973c7180baceb9c84d074b516a4

From the pod, you can create a container to run the wasm bytecode program in isolation.

# Create the container instance. Output will be different from example.
sudo crictl create $POD_ID container_wasi.json sandbox_config.json
1d056e4a8a168f0c76af122d42c98510670255b16242e81f8e8bce8bd3a4476f

Finally, start the container and see the output from the wasm application.

# List the container, the state should be `Created`
sudo crictl ps -a

CONTAINER           IMAGE                           CREATED              STATE               NAME                     ATTEMPT             POD ID
1d056e4a8a168       hydai/wasm-wasi-example:latest   About a minute ago   Created             podsandbox1-wasm-wasi   0                   7992e75df00cc

# Start the container
sudo crictl start 1d056e4a8a168f0c76af122d42c98510670255b16242e81f8e8bce8bd3a4476f
1d056e4a8a168f0c76af122d42c98510670255b16242e81f8e8bce8bd3a4476f

# Check the container status again.# If the container is not finishing its job, you will see the Running state# Because this example is very tiny. You may see Exited at this moment.
sudo crictl ps -a
CONTAINER           IMAGE                           CREATED              STATE               NAME                     ATTEMPT             POD ID
1d056e4a8a168       hydai/wasm-wasi-example:latest   About a minute ago   Running             podsandbox1-wasm-wasi   0                   7992e75df00cc

# When the container is finished. You can see the state becomes Exited.
sudo crictl ps -a
CONTAINER           IMAGE                           CREATED              STATE               NAME                     ATTEMPT             POD ID
1d056e4a8a168       hydai/wasm-wasi-example:latest   About a minute ago   Exited              podsandbox1-wasm-wasi   0                   7992e75df00cc

# Check the container's logs
sudo crictl logs 1d056e4a8a168f0c76af122d42c98510670255b16242e81f8e8bce8bd3a4476f

Test 1: Print Random Number
Random number: 960251471

Test 2: Print Random Bytes
Random bytes: [50, 222, 62, 128, 120, 26, 64, 42, 210, 137, 176, 90, 60, 24, 183, 56, 150, 35, 209, 211, 141, 146, 2, 61, 215, 167, 194, 1, 15, 44, 156, 27, 179, 23, 241, 138, 71, 32, 173, 159, 180, 21, 198, 197, 247, 80, 35, 75, 245, 31, 6, 246, 23, 54, 9, 192, 3, 103, 72, 186, 39, 182, 248, 80, 146, 70, 244, 28, 166, 197, 17, 42, 109, 245, 83, 35, 106, 130, 233, 143, 90, 78, 155, 29, 230, 34, 58, 49, 234, 230, 145, 119, 83, 44, 111, 57, 164, 82, 120, 183, 194, 201, 133, 106, 3, 73, 164, 155, 224, 218, 73, 31, 54, 28, 124, 2, 38, 253, 114, 222, 217, 202, 59, 138, 155, 71, 178, 113]

Test 3: Call an echo function
Printed from wasi: This is from a main function
This is from a main function

Test 4: Print Environment Variables
The env vars are as follows.
PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM: xterm
HOSTNAME: crictl_host
PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
The args are as follows.
/var/lib/containers/storage/overlay/006e7cf16e82dc7052994232c436991f429109edea14a8437e74f601b5ee1e83/merged/wasi_example_main.wasm
50000000

Test 5: Create a file `/tmp.txt` with content `This is in a file`

Test 6: Read the content from the previous file
File content is This is in a file

Test 7: Delete the previous file

What's next

In this article, we have seen how to start, run, and manage WasmEdge applications using Docker-like CRI-O tools.

Our next step is to use Kubernetes to manage WasmEdge containers. To accomplish that, we will need to install a runner binary inside Kubernetes so that it could support regular Docker images and wasm bytecode images at the same time.

Join us in the WebAssembly revolution!

👉 Slack Channel: #wasmedge on CNCF Slack channel

👉 Mailing list: Send an email to WasmEdge@googlegroups.com

👉 Be a contributor: checkout our wish list to start contributing!

Saving Uniswap v1

alabulei1 — Fri, 30 Oct 2020 16:15:08 +0000

New Ethereum compatible projects like the Oasis Ethereum ParaTime are choosing Uniswap v1 over v2 for good reasons. Few understand this. 🤔

In the world of software, a new release typically means improvements every user should upgrade to. 🎉 For Uniswap, however, v2 is simply different software than v1. Uniswap v2 is a complete rewrite with exciting new features, but the developers also made compromises in terms of cost, complexity, (de)centralization, and openness. 😿 As a result, for many users and developers, there are compelling reasons to stick with v1. I think the community should invest the effort to keep Uniswap v1 software maintained and viable. Now, let me explain.

A brief history

The idea of Automated Market Making (AMM) is not new. Bancor, one of the most successful ICO projects (in terms of money raised), is built on the idea of AMM. However, Bancor never took off because it needlessly complicated the user experience by bringing in a “smart token” into the system, which is great for the ICO but adds little value to the trading experience itself. Furthermore, while Bancor’s smart contracts are open source, its user interface application is never fully open making it difficult for outside developers to build or improve upon it.

Then comes Uniswap. Created by a young and ambitious developer in a rising programming language (Vyper), it laser-focused on the trader’s user experience. Uniswap v1 has a very simple AMM formula. It is easy to understand and use, with an intuitive UI. Uniswap v1 smart contracts are highly optimized for gas efficiency. Its entire code base is open source and easily reusable by developers in the community. I, as a developer and crypto user, loved Uniswap v1.

Then, comes Uniswap v2. It is an engineering achievement and designed to meet expectations of its investors and liquidity providers — as evident from the popularity of the UNI token. For users, it enables direct swapping between pairs of ERC-20 tokens as well as flash swaps in atomic transactions. But it also makes important compromises and sacrifices. In the rest of this article, I will make the case for continued v1 development by the community.

Centralization / Decentralization

The first page of the Uniswap v2 whitepaper reveals that, unlike v1, a centralized private key could take a percentage (0.05%) of the fee on every trade.

“there is a private key that has the ability to update a variable on the factory contract to turn on an on-chain 5-basis-point fee on trades.” — The Uniswap v2 whitepaper

This fee is sent to an address of the contract’s owner controls. The mere existence of an “owner” is uncomfortable in a project that champions decentralization.

Furthermore, Uniswap v2 apparently allows a centralized party to mint and distribute governance tokens for the entire project. While I appreciate UNI airdrop, it is a slippery slope toward centralization.

Gas cost

One of the best features of Uniswap v1 is its gas efficiency. That is especially important for users as Ethereum gas fees reach new heights during the DeFi boom.

However, Uniswap v2, with its complicated and inter-dependent smart contracts, costs much more in gas fees compared with v1. Uniswap v2 relies on smart contracts ranging from the Factory, Router (V2), Pair and Pair ERC20 contracts, along with a Library contract for common utilities. Let’s take the proxy contract as an example. The proxy contract on Uniswap v1 is 46 bytes, however, the same contract on Uniswap v2 is 4349 bytes. The increased complexity translates to inflated gas fees for users.

“I noticed the fees are a bit higher and it actually have me a notification to use v1 for my swap” - Comment from Reddit.

Now, to be fair, the added complexity does bring use of more features.

ERC-20 to ERC-20 swap and quick swap are nice-to-have features.
The pricing oracle is not relevant to me as an end-user.

As a user, I prefer the cheaper and simpler v1 when I just need to swap ERC-20 tokens against ETH.

i18n

Many non-English crypto users are dismayed to find that Uniswap v2 does not provide i18n support for non-English languages. Uniswap v1 already had decent i18n support, and this feature was actually removed in v2.

Fun fact: the Uniswap v1 i18n interface for non-English languages was contributed by Maggie Wang from CyberMiles.

As the crypto community grows more diverse, Uniswap’s regression to English-only does not bode well for its position as a worldwide DeFi leader.

Portability

The Uniswap v2 user interface (UI) is a complex JavaScript application. It is designed to deploy on Ethereum mainnet and various testnets. It requires a major effort to deploy the Uniswap v2 UI on any other Ethereum compatible blockchain as extensive code level changes must be made to modify hardcoded values such as the following.

The on-chain addresses and hash values of various important contracts, such as the Router.
The web3 gateway provider’s URL structure.
The chain ID of the host blockchain.
Token list locations.

In contrast, the Uniswap v1 UI code is much simpler and cleaner. It is easy to run the Uniswap v1 UI on an alternative Ethereum blockchain, such as the Oasis Ethereum ParaTime chain.

User interface

The Uniswap v2 UI was originally deployed with a toggle button where users could choose to use v1. Whilst the toggle did not actually fully allow the user to stay on v1 — i.e. functions in relation to liquidity would automatically default to operating partially via the V2 smart contracts, the toggle has since been removed. Put simply, the current “official” Uniswap UI is geared wholly and solely towards herding users to the v2 smart contracts and liquidity pools. Leaving the original v1 smart contracts on the sidelines.

What’s next

Most of Uniswap liquidity has moved to v2. According to data from the official Uniswap V1 analytics tool in later Oct 2020, there are just $4 million in liquidity on Uniswap v1, and 742 transactions in the past 24 hours. That is a fraction of the volume of Uniswap v2, which is $2.9 billion in liquidity and 137,255 transactions in the past 24 hours.

Due to the strong network effects of exchanges, there is probably no turning back on Ethereum mainnet, although I will miss v1’s simplicity and low fees.

However, on emerging Ethereum compatible blockchains, I believe many developers and users will still choose Uniswap v1 as the go-to DeFi exchange. The Uniswap v1 codebase should be revived and maintained by the community for this very purpose.

Face Detection in Node.js with Rust and WebAssembly

alabulei1 — Wed, 23 Sep 2020 10:14:54 +0000

We introduced how to call Rust functions from Node.js in the last article. This article will introduce how to write a Node.js-based AI as a Service application.

Today’s dominant programming language for AI is Python. Yet, the programming language for the web is JavaScript. To provide AI capabilities as a service on the web, we need to wrap AI algorithms in JavaScript, particularly Node.js.

However, neither Python nor JavaScript by itself is suitable for computationally intensive AI applications. They are high-level, ie, slow, languages with heavy-weight runtimes. Their ease-of-use comes at the cost of low performance. Python got around this by wrapping AI computation in native C/C++ modules. Node.js could do the same, but we have a better way — WebAssembly.

WebAssembly VMs provide tight integration with Node.js and other JavaScript runtimes. They are highly performant, memory safe, secure by default, and portable across operating systems. However, our approach combines the best features of WebAssembly and native code.

How it works

The Node.js-based AI as a Service application consists of three parts.

The Node.js application provides web services and calls the WebAssembly function to perform computationally intensive tasks such as AI inference.
The data preparation, post-processing, and integration with other systems, are done by a WebAssembly function. Initially, we support Rust. The application developer must write this function.
The actual execution of the AI model is done by native code to maximize performance. This part of the code is very short and is reviewed for security and safety. Application developers just call this native program from the WebAssembly function — much like how native functions are used in Python and Node.js today.

Let's look at an example now!

A face detection example

The face detection web service allows a user to upload a photo, and it displays the image with all pictures marked in green boxes.

The Rust source code for executing the MTCNN face detection model is based on Cetra's excellent tutorial: Face Detection with Tensorflow Rust. We made changes to make the Tensorflow library work in WebAssembly.

The Node.js application handles the file uploading and the response.

app.post('/infer', function (req, res) {
  let image_file = req.files.image_file;
  var result_filename = uuidv4() + ".png";

  // Call the infer() function from WebAssembly (SSVM)
  var res = infer(req.body.detection_threshold, image_file.data);

  fs.writeFileSync("public/" + result_filename, res);
  res.send('<img src="' +  result_filename + '"/>');
});

As you can see, the JavaScript app simply passes the image data and a parameter called detection_threshold, which specifies the smallest face to be detected, to the infer() function, and then saves the return value into an image file on the server. The infer() function is written in Rust and compiled into WebAssembly so that it can be called from JavaScript.

The infer() function flattens the input image data into an array. It sets up a TensorFlow model and uses the flattened image data as input to the model. The TensorFlow model execution returns a set of numbers indicating the coordinates for the four corners of each face box. The infer() function then draws a green box around each face, and then it saves the modified image into a PNG file on the webserver.

#[wasm_bindgen]
pub fn infer(detection_threshold: &str, image_data: &[u8]) -> Vec<u8> {
    let mut dt = detection_threshold;
    ... ...
    let mut img = image::load_from_memory(image_data).unwrap();

    // Run the tensorflow model using the face_detection_mtcnn native wrapper
    let mut cmd = Command::new("face_detection_mtcnn");
    // Pass in some arguments
    cmd.arg(img.width().to_string())
        .arg(img.height().to_string())
        .arg(dt);
    // The image bytes data is passed in via STDIN
    for (_x, _y, rgb) in img.pixels() {
        cmd.stdin_u8(rgb[2] as u8)
            .stdin_u8(rgb[1] as u8)
            .stdin_u8(rgb[0] as u8);
    }
    let out = cmd.output();

    // Draw boxes from the result JSON array
    let line = Pixel::from_slice(&[0, 255, 0, 0]);
    let stdout_json: Value = from_str(str::from_utf8(&out.stdout).expect("[]")).unwrap();
    let stdout_vec = stdout_json.as_array().unwrap();
    for i in 0..stdout_vec.len() {
        let xy = stdout_vec[i].as_array().unwrap();
        let x1: i32 = xy[0].as_f64().unwrap() as i32;
        let y1: i32 = xy[1].as_f64().unwrap() as i32;
        let x2: i32 = xy[2].as_f64().unwrap() as i32;
        let y2: i32 = xy[3].as_f64().unwrap() as i32;
        let rect = Rect::at(x1, y1).of_size((x2 - x1) as u32, (y2 - y1) as u32);
        draw_hollow_rect_mut(&mut img, rect, *line);
    }   
    let mut buf = Vec::new();
    // Write the result image into STDOUT
    img.write_to(&mut buf, image::ImageOutputFormat::Png).expect("Unable to write");
    return buf;
}

The face_detection_mtcnn command runs the MTCNN TensorFlow model in native code. It takes three arguments, image width, image height, and detection threshold. The actual image data prepared as flattened RGB values is passed in from the WebAssembly infer() via STDIN. The result from the model is encoded in JSON and returned via the STDOUT.

Notice how we passed the model parameter detection_threshold the model tensor named min_size, and then used the input tensor to pass in the input image data. The box tensor is used to retrieves the results from the model.

fn main() -> Result<(), Box<dyn Error>> {
    // Get the arguments passed in from WebAssembly
    let args: Vec<String> = env::args().collect();
    let img_width: u64 = args[1].parse::<u64>().unwrap();
    let img_height: u64 = args[2].parse::<u64>().unwrap();
    let detection_threshold: f32 = args[3].parse::<f32>().unwrap();
    let mut buffer: Vec<u8> = Vec::new();
    let mut flattened: Vec<f32> = Vec::new();

    // The image bytes are read from STDIN
    io::stdin().read_to_end(&mut buffer)?;
    for num in buffer {
        flattened.push(num.into());
    }

    // Load up the graph as a byte array and create a tensorflow graph.
    let model = include_bytes!("mtcnn.pb");
    let mut graph = Graph::new();
    graph.import_graph_def(&*model, &ImportGraphDefOptions::new())?;

    let mut args = SessionRunArgs::new();
    // The `input` tensor expects BGR pixel data from the input image
    let input = Tensor::new(&[img_height, img_width, 3]).with_values(&flattened)?;
    args.add_feed(&graph.operation_by_name_required("input")?, 0, &input);

    // The `min_size` tensor takes the detection_threshold argument
    let min_size = Tensor::new(&[]).with_values(&[detection_threshold])?;
    args.add_feed(&graph.operation_by_name_required("min_size")?, 0, &min_size);

    // Default input params for the model
    let thresholds = Tensor::new(&[3]).with_values(&[0.6f32, 0.7f32, 0.7f32])?;
    args.add_feed(&graph.operation_by_name_required("thresholds")?, 0, &thresholds);
    let factor = Tensor::new(&[]).with_values(&[0.709f32])?;
    args.add_feed(&graph.operation_by_name_required("factor")?, 0, &factor);

    // Request the following outputs after the session runs.
    let bbox = args.request_fetch(&graph.operation_by_name_required("box")?, 0);

    let session = Session::new(&SessionOptions::new(), &graph)?;
    session.run(&mut args)?;

    // Get the bounding boxes
    let bbox_res: Tensor<f32> = args.fetch(bbox)?;
    let mut iter = 0;
    let mut json_vec: Vec<[f32; 4]> = Vec::new();
    while (iter * 4) < bbox_res.len() {
        json_vec.push([
            bbox_res[4 * iter + 1], // x1
            bbox_res[4 * iter],     // y1
            bbox_res[4 * iter + 3], // x2
            bbox_res[4 * iter + 2], // y2
        ]);
        iter += 1;
    }
    let json_obj = json!(json_vec);
    // Return result JSON in STDOUT
    println!("{}", json_obj.to_string()); 
    Ok(())
}

Our goal is to create native execution wrappers for common AI models so that developers can just use them as libraries.

Deploy the face detection example

As prerequisites, you will need to install Rust, Node.js, the Second State WebAssembly VM, and the ssvmup tool. Check out the instruction for the steps, or simply use our Docker image. You will also need the TensorFlow library on your machine.

$ wget https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-gpu-linux-x86_64-1.15.0.tar.gz
$ sudo tar -C /usr/ -xzf libtensorflow-gpu-linux-x86_64-1.15.0.tar.gz

To deploy the face detection example, we start from the native TensorFlow model driver. You can compile it from Rust source code in this project.

# in the native_model_zoo/face_detection_mtcnn directory
$ cargo install --path .

Next, go to the web application project. Run the ssvmup command to build the WebAssembly function from Rust. Recall that this WebAssembly function performs data preparation logic for the web application.

# in the nodejs/face_detection_service directory
$ ssvmup build

With the WebAssembly function built, you can now start the Node.js application.

$ npm i express express-fileupload uuid

$ cd node
$ node server.js

The web service is now available at port 8080 of your computer. Try it with your own selfies or family and group photos!

The TensorFlow model zoo

The native Rust crate face_detection_mtcnn is a fragile wrapper around the TensorFlow library. It loads the trained TensorFlow model, known as a frozen saved model, sets up inputs for the model, executes the model, and retrieves output values from the model.

In fact, our wrapper only retrieves the box coordinates around detected faces. The model actually provides a confidence level for each detected face and position of eyes, mouth, and nose on each face. By changing the retrieve tensor names in the model, the wrapper could get this information and return to the WASM function.

If you would like to use a different model, it should be fairly easy to follow the example and create a wrapper for your own model. You just need to know the input and output of tensor names and their data types.

To achieve this goal, we create a project, called the native model zoo, to develop ready-to-use Rust wrappers for as many TensorFlow models as possible.

What's next

In this article, we demonstrated how to implement a real-world AI as a Service use case in Node.js using Rust and WebAssembly. Our approach provides a framework for the entire community to contribute to a “model zoo”, which can serve as the AI library for more application developers.

In the next tutorial, we will review another TensorFlow model for image classification and demonstrate how the wrapper can be extended to support a whole class of similar models.

Raspberry Pi on steroids with Rust and WebAssembly

alabulei1 — Fri, 10 Jul 2020 11:22:17 +0000

The Raspberry Pi is a very powerful computer in a tiny package. The cheapest option, the Raspberry Pi Zero, is capable of running a fully featured Linux distribution and driving a high definition display. It is the size of 3 coins (US Quarters) and costs $5. At $10, the Raspberry Pi Zero W comes with integrated WiFi and Bluetooth.

BTW, we are giving away FREE Raspberry Pi kits! All you need to do is to follow our simple examples and create a Node.js app with Rust. It is easy as Pi! 🍕

With a generic ARM CPU and easy networking, the Raspberry Pi can easily become a personal application server for you. For example, you can put a web application (eg a collaborative record keeping app) on a Pi, bring it to a meeting, and make it accessible to everyone in the room. You do not even need the Internet. It is completely decentralized and censorship resistant.

The personal server is especially useful for developers. You can have a separate environment to deploy and test your server-side applications without having to mess with your laptop. The personal dev server is like Docker on steroids.

However, the $5 Pi is also, obviously, a resource constrained server. It only has 512MB of RAM and a single CPU core. It could benefit greatly from a lightweight and high-performance application runtime. But at the same time, we still like the ease-of-use and developer productivity of “heavy weight” scripting languages such as JavaScript. We want best of both worlds.

Our solution is to deploy high-performance and resource-efficient Rust functions inside Node.js JavaScript apps. The Second State WebAssembly VM (SSVM) provides a light, efficient, secure, and portable runtime for Rust code. In this article, I will teach you how to set it up.

Setup Raspberry Pi OS

The easiest way to set up your Raspberry device to install the Raspberry Pi OS from a MicroSD card. The Raspberry Pi OS is a Debian-based Linux distribution that is suitable for both desktop and server uses. You can buy a blank MicroSD card and use the Raspberry Pi Imager to load the NOOBS system on it. Or, you can buy one of those MicroSD cards with NOOBS pre-loaded.

Put the MicroSD card into your Pi device’s card slot, connect an HDMI display, keyboard, mouse, and power up! Follow the on-screen instructions to install Raspberry Pi OS. From there, you can create a user account, connect to WiFi, turn on SSH, and open the command line terminal. In order to use the Pi device as a “headless” server, you could request a static IP address from your router. In the future, you can just power it on, and connect to it via SSH from your laptop — there is no need for display, keyboard, and mouse. Once you are set up, use the following command to find your Pi’s IP address on your local network.

$ hostname -I
192.168.2.108 172.17.0.1

As with all new Linux installations, it is a good idea to update and upgrade to the latest packages. Run the command below and be patient. It could take an hour.

$ `sudo apt update && sudo apt upgrade`

Next, run the following command to install essential developer libraries.

$ sudo apt install build-essential curl libboost-all-dev

Install Node.js and SSVM

The following two commands install Node.js on your Pi.

$ `curl ``-``sL https``:``//deb.nodesource.com/setup_10.x | sudo bash -`
`$ sudo apt install nodejs`

From here, you can use npm to install modules. Here we install the Second State VM (ssvm) to support high performance Rust functions in Node.js applications.

$ npm install ssvm

Next, let’s try to run a couple of demo applications.

Run a demo Node.js application

Get the demo application from the Internet, and unzip the compressed archive.

`$ curl -O https://www.secondstate.io/download/quadratic.zip`
`$ unzip quadratic.zip`

Next, run a test program to make sure that the Node.js JavaScript function can correctly call the Rust function through SSVM.

`$ cd quadratic/node`
`$ node test.js`
`[0.5,-3.0]`

Start the Node.js server application from the command line terminal.

`$ npm install express // Required for the web app.`
`$ cd quadratic/node`
`$ node server.js`

Point the browser to http://localhost:8080/ or you can access it from another computer on your network.

It is a web application that teaches math and solves quadratic equations. It could come really handy in a small group in a classroom!

Install developer tools

You do not really need developer tools on a personal server. But the Raspberry Pi device is powerful enough to compile and build software. In fact, one of its common uses cases is to teach programming. The Raspberry Pi OS comes pre-loaded with developer tools for Java, Python, and Scratch. Now, let’s install some serious tools on it! I always install Git on all my development environments.

$ sudo apt install git

The following command installs the Rust compiler toolchain on the Pi.

`$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh`

Run the following command to set up the correct path without logging out and back in again.

$ source $HOME/.cargo/env

Next, you can clone our Rust learning repository, and learn from examples.

$ git clone https://github.com/second-state/wasm-learning.git

Here is the hello world example. Have fun!

$ cd wasm-learning/rust/hello
$ cargo build
   Compiling hello v0.1.0 (/home/pi/Dev/wasm-learning/rust/hello)
    Finished dev [unoptimized + debuginfo] target(s) in 4.35s
$ target/debug/hello
Hello, world!

Check out the official Rust web site and the Rust by Example books for more learning resources!

Next steps

Now you have everything you need on the Raspberry Pi device. The next steps are to learn more about creating high-performance and resource-constrained Node.js web applications on your $5 Raspberry Pi personal dev server.

Have fun, and let me know how you used your Raspberry Pi device!

Don’t forget to create and publish a Node.js app to receive your FREE Raspberry Pi. Can’t wait to see what you can do with Rust and WebAssembly!

Stay in touch! Get the email newsletter on Rust, WebAssembly, serverless, blockchain, and AI.

How to call Rust functions from Node.js 🦀

alabulei1 — Tue, 09 Jun 2020 11:03:04 +0000

Create JavaScript + Rust hybrid applications in Node.js. 🦄

The Rust + Node.js hybrid apps combine Rust's performance, WebAssembly's security and portability, and JavaScript's ease-of-use. A typical Rust + Node.js hybrid app works like this.

The host application is a Node.js web application written in JavaScript. It makes WebAssembly function calls.
The WebAssembly bytecode program is written in Rust. It runs inside the open source Second State WebAssembly VM (SSVM), and is called from the Node.js web application.

Hello world for VSCode

We take this GitHub repo as an example.

second-state / wasmedge-nodejs-starter

A template project to run Rust functions in Node.js through the Second State WebAssembly engine.

The Rust functions are in the src directory. You can put high-performance workload into Rust functions.
The JavaScript functions are in the node directory and they can access the Rust functions.
Use the node node/app.js command to run the application in Node.js.

The secret of no-software is VS codespaces. Code, build, and run directly from inside the browser.

VS Codespaces runs entirely in your browser and costs around $1 per workday. It is cheaper than a cup of coffee in the office. Alternatively, use locally installed VSCode and Docker, and launch the IDE with your remote git repository.

1 First, open the VS Codespaces web site and log in with your Azure account. You can get a free Azure account.

2 Next, create a new Codespace. Put your forked repository into the Git Repository field.

3 Then open the src/lib.rs, node/app.js, and Cargo.toml files and see how the Node.js express app calls the Rust function to say hello.

4 Click on the Run button on the left panel, and then the Launch Program at the top to build and run the application.

The Terminal window at the bottom shows the build progress. It builds the Rust program and then launches the Node.js app.

The Debug window shows the Node.js server running and waiting for web requests.

5 Now, you have two choices. You could use the proxy link for 127.0.0.1:3000 to access the running server in a browser.

Or, you could open another terminal window in the IDE via the Terminal -> New Terminal menu.

From the terminal window, you can test the local server.

$ curl http://127.0.0.1:3000/?name=SSVM
hello SSVM

More exercises

Now, you can copy and paste code from this project.

src/lib.rs --> Replace with code here
Cargo.toml --> Replace with code here
node/app.js --> Replace with code here

Click on Run to see the build output in the Terminal window, and application console output in Debug window.

Try to log into GitHub from the IDE, and use the IDE's GitHub integration features to commit the changes, push the changes back into your forked repository, and perhaps even send us a Pull Request from the IDE!

Resources

The Second State VM (SSVM) is a high-performance WebAssembly virtual machine designed for server-side applications.
The SSVM NPM addon provides access to the SSVM, and programs in it, through a Node.js host application.
The SSVM ready tool, ssvmup is a toolchain for compiling Rust programs into WebAssembly, and then make them accessible from JavaScripts via the SSVM.

Stay in touch! Get the email newsletter on Rust, WebAssembly, serverless, blockchain, and AI.

WebAssembly on the server side

alabulei1 — Thu, 05 Dec 2019 05:46:41 +0000

WebAssembly on the server side

Dec 4 '19 Comments: 1 Answers: 0

If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. WebAssembly on the server is the future of computing. The co-founder of Docker, quoting Solomon Hykes.

And an article I saw recently reads as Wasm gains popularity on the client-side, Wasm is also…

Open Full Question