chore: reordered contents

Signed-off-by: Adithya Krishna <[email protected]>

i18n/zh/docusaurus-plugin-content-docs/current/embed/use-case/serverless/_category_.json → docs/start/usage/serverless/_category_.json

@@ -1,5 +1,5 @@
 {
-  "label": "Serviceless Platforms",
+  "label": "Serverless Platforms",
   "position": 9,
   "link": {
     "type": "generated-index",

docs/start/usage/use-cases.md

@@ -8,9 +8,9 @@ Featuring AOT compiler optimization, WasmEdge is one of the fastest WebAssembly
 
 - WasmEdge provides a lightweight, secure and high-performance runtime for microservices. It is fully compatible with application service frameworks such as Dapr, and service orchestrators like Kubernetes. WasmEdge microservices can run on edge servers, and have access to distributed cache, to support both stateless and stateful business logic functions for modern web apps. Also related: Serverless function-as-a-service in public clouds.
 
-- [Serverless SaaS (Software-as-a-Service)](../../embed/use-case/serverless-saas.md) functions enables users to extend and customize their SaaS experience without operating their own API callback servers. The serverless functions can be embedded into the SaaS or reside on edge servers next to the SaaS servers. Developers simply upload functions to respond to SaaS events or to connect SaaS APIs.
+- [Serverless SaaS (Software-as-a-Service)](./serverless/serverless-platforms) functions enables users to extend and customize their SaaS experience without operating their own API callback servers. The serverless functions can be embedded into the SaaS or reside on edge servers next to the SaaS servers. Developers simply upload functions to respond to SaaS events or to connect SaaS APIs.
 
-- [Smart device apps](../../embed/use-case/wasm-smart-devices.md) could embed WasmEdge as a middleware runtime to render interactive content on the UI, connect to native device drivers, and access specialized hardware features (i.e, the GPU for AI inference). The benefits of the WasmEdge runtime over native-compiled machine code include security, safety, portability, manageability, and developer productivity. WasmEdge runs on Android, OpenHarmony, and seL4 RTOS devices.
+- [Smart device apps](./wasm-smart-devices.md) could embed WasmEdge as a middleware runtime to render interactive content on the UI, connect to native device drivers, and access specialized hardware features (i.e, the GPU for AI inference). The benefits of the WasmEdge runtime over native-compiled machine code include security, safety, portability, manageability, and developer productivity. WasmEdge runs on Android, OpenHarmony, and seL4 RTOS devices.
 
 - WasmEdge could support high performance DSLs (Domain Specific Languages) or act as a cloud-native JavaScript runtime by embedding a JS execution engine or interpreter.
 

i18n/zh/docusaurus-plugin-content-docs/current/start/usage/serverless/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Serverless Platforms",
+  "position": 9,
+  "link": {
+    "type": "generated-index",
+    "description": "Run WebAssembly as an alternative lightweight runtime side-by-side with Docker and microVMs in cloud native infrastructure"
+  }
+}

i18n/zh/docusaurus-plugin-content-docs/current/start/usage/serverless/aws.md

@@ -0,0 +1,272 @@
+---
+sidebar_position: 1
+---
+
+# WebAssembly Serverless Functions in AWS Lambda
+
+In this article, we will show you two serverless functions in Rust and WasmEdge deployed on AWS Lambda. One is the image processing function, the other one is the TensorFlow inference function.
+
+> For the insight on why WasmEdge on AWS Lambda, please refer to the article [WebAssembly Serverless Functions in AWS Lambda](https://www.secondstate.io/articles/webassembly-serverless-functions-in-aws-lambda/)
+
+## Prerequisites
+
+Since our demo WebAssembly functions are written in Rust, you will need a [Rust compiler](https://www.rust-lang.org/tools/install). Make sure that you install the `wasm32-wasi` compiler target as follows, in order to generate WebAssembly bytecode.
+
+```bash
+rustup target add wasm32-wasi
+```
+
+The demo application front end is written in [Next.js](https://nextjs.org/), and deployed on AWS Lambda. We will assume that you already have the basic knowledge of how to work with Next.js and Lambda.
+
+## 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](https://second-state.github.io/aws-lambda-wasm-runtime/) deployed through GitHub Pages is available.
+
+Fork the [demo application’s GitHub repo](https://github.com/second-state/aws-lambda-wasm-runtime) to get started. To deploy the application on AWS Lambda, follow the guide in the repository [README](https://github.com/second-state/aws-lambda-wasm-runtime/blob/tensorflow/README.md).
+
+### Create the function
+
+This repo is a standard Next.js application. 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`.
+
+```rust
+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.
+
+```bash
+cd api/functions/image-grayscale/
+cargo build --release --target wasm32-wasi
+```
+
+Copy the build artifacts to the `api` folder.
+
+```bash
+cp target/wasm32-wasi/release/grayscale.wasm ../../
+```
+
+> When we build the docker image, `api/pre.sh` is executed. `pre.sh` installs the WasmEdge runtime, and then compiles each WebAssembly bytecode program into a native `so` library for faster execution.
+
+### Create the service script to load the function
+
+The [`api/hello.js`](https://github.com/second-state/aws-lambda-wasm-runtime/blob/main/api/hello.js) script loads the WasmEdge runtime, starts the compiled WebAssembly program in WasmEdge, and passes the uploaded image data via `STDIN`. Notice that [`api/hello.js`](https://github.com/second-state/aws-lambda-wasm-runtime/blob/main/api/hello.js) runs the compiled `grayscale.so` file generated by [`api/pre.sh`](https://github.com/second-state/aws-lambda-wasm-runtime/blob/main/api/pre.sh) for better performance.
+
+```javascript
+const { spawn } = require('child_process');
+const path = require('path');
+
+function _runWasm(reqBody) {
+  return new Promise((resolve) => {
+    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);
+      resolve(buf);
+    });
+
+    wasmedge.stdin.write(reqBody);
+    wasmedge.stdin.end('');
+  });
+}
+```
+
+The `exports.handler` part of `hello.js` exports an async function handler, used to handle different events every time the serverless function is called. In this example, we simply process the image by calling the function above and return the result, but more complicated event-handling behavior may be defined based on your need. We also need to return some `Access-Control-Allow` headers to avoid [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) errors when calling the serverless function from a browser. You can read more about CORS errors [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors) if you encounter them when replicating our example.
+
+```javascript
+exports.handler = async function (event, context) {
+  var typedArray = new Uint8Array(
+    event.body.match(/[\da-f]{2}/gi).map(function (h) {
+      return parseInt(h, 16);
+    }),
+  );
+  let buf = await _runWasm(typedArray);
+  return {
+    statusCode: 200,
+    headers: {
+      'Access-Control-Allow-Headers':
+        'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token',
+      'Access-Control-Allow-Origin': '*',
+      'Access-Control-Allow-Methods':
+        'DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT',
+    },
+    body: buf.toString('hex'),
+  };
+};
+```
+
+### Build the Docker image for Lambda deployment
+
+Now we have the WebAssembly bytecode function and the script to load and connect to the web request. In order to deploy them as a function service on AWS Lambda, you still need to package the whole thing into a Docker image.
+
+We are not going to cover in detail about how to build the Docker image and deploy on AWS Lambda, as there are detailed steps in the [Deploy section of the repository README](https://github.com/second-state/aws-lambda-wasm-runtime/blob/tensorflow/README.md#deploy). However, we will highlight some lines in the [`Dockerfile`](https://github.com/second-state/aws-lambda-wasm-runtime/blob/tensorflow/api/Dockerfile) for you to avoid some pitfalls.
+
+```dockerfile
+FROM public.ecr.aws/lambda/nodejs:14
+
+# Change directory to /var/task
+WORKDIR /var/task
+
+RUN yum update -y && yum install -y curl tar gzip
+
+# Bundle and pre-compile the wasm files
+COPY *.wasm ./
+COPY pre.sh ./
+RUN chmod +x pre.sh
+RUN ./pre.sh
+
+# Bundle the JS files
+COPY *.js ./
+
+CMD [ "hello.handler" ]
+```
+
+First, we are building the image from [AWS Lambda's Node.js base image](https://hub.docker.com/r/amazon/aws-lambda-nodejs). The advantage of using AWS Lambda's base image is that it includes the [Lambda Runtime Interface Client (RIC)](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client), which we need to implement in our Docker image as it is required by AWS Lambda. The Amazon Linux uses `yum` as the package manager.
+
+> These base images contain the Amazon Linux Base operating system, the runtime for a given language, dependencies and the Lambda Runtime Interface Client (RIC), which implements the Lambda [Runtime API](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html). The Lambda Runtime Interface Client allows your runtime to receive requests from and send requests to the Lambda service.
+
+Second, we need to put our function and all its dependencies in the `/var/task` directory. Files in other folders will not be executed by AWS Lambda.
+
+Third, we need to define the default command when we start our container. `CMD [ "hello.handler" ]` means that we will call the `handler` function in `hello.js` whenever our serverless function is called. Recall that we have defined and exported the handler function in the previous steps through `exports.handler = ...` in `hello.js`.
+
+### Optional: test the Docker image locally
+
+Docker images built from AWS Lambda's base images can be tested locally following [this guide](https://docs.aws.amazon.com/lambda/latest/dg/images-test.html). Local testing requires [AWS Lambda Runtime Interface Emulator (RIE)](https://github.com/aws/aws-lambda-runtime-interface-emulator), which is already installed in all of AWS Lambda's base images. To test your image, first, start the Docker container by running:
+
+```bash
+docker run -p 9000:8080  myfunction:latest
+```
+
+This command sets a function endpoint on your local machine at `http://localhost:9000/2015-03-31/functions/function/invocations`.
+
+Then, from a separate terminal window, run:
+
+```bash
+curl -XPOST "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
+```
+
+And you should get your expected output in the terminal.
+
+If you don't want to use a base image from AWS Lambda, you can also use your own base image and install RIC and/or RIE while building your Docker image. Just follow **Create an image from an alternative base image** section from [this guide](https://docs.aws.amazon.com/lambda/latest/dg/images-create.html).
+
+That's it! After building your Docker image, you can deploy it to AWS Lambda following steps outlined in the repository [README](https://github.com/second-state/aws-lambda-wasm-runtime/blob/tensorflow/README.md#deploy). Now your serverless function is ready to rock!
+
+## Example 2: AI inference
+
+The [second demo](https://github.com/second-state/aws-lambda-wasm-runtime/tree/tensorflow) 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](https://github.com/second-state/aws-lambda-wasm-runtime/tree/tensorflow) as the previous example but in the `tensorflow` branch. 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.
+
+```rust
+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.
+
+```bash
+cd api/functions/image-classification/
+cargo build --release --target wasm32-wasi
+```
+
+Copy the build artifacts to the `api` folder.
+
+```bash
+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`](https://github.com/second-state/aws-lambda-wasm-runtime/blob/tensorflow/api/hello.js) script loads the WasmEdge runtime, starts the compiled WebAssembly program in WasmEdge, and passes the uploaded image data via `STDIN`. Notice [`api/hello.js`](https://github.com/second-state/aws-lambda-wasm-runtime/blob/tensorflow/api/hello.js) runs the compiled `classify.so` file generated by [`api/pre.sh`](https://github.com/second-state/aws-lambda-wasm-runtime/blob/tensorflow/api/pre.sh) for better performance. The handler function is similar to our previous example, and is omitted here.
+
+```javascript
+const { spawn } = require('child_process');
+const path = require('path');
+
+function _runWasm(reqBody) {
+  return new Promise(resolve => {
+    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) => {
+      resolve(d.join(''));
+    });
+
+    wasmedge.stdin.write(reqBody);
+    wasmedge.stdin.end('');
+  });
+}
+
+exports.handler = ... // _runWasm(reqBody) is called in the handler
+```
+
+You can build your Docker image and deploy the function in the same way as outlined in the previous example. Now you have created a web app for subject classification!
+
+Next, it's your turn to use the [aws-lambda-wasm-runtime repo](https://github.com/second-state/aws-lambda-wasm-runtime/tree/main) as a template to develop Rust serverless function on AWS Lambda. Looking forward to your great work.