Practice your Go WebAssembly with a Game
Tags: webassembly, go, docker
Published: 2019-02-21 05:52:30

---
title: Practice your Go WebAssembly with a Game
published: true
tags: webassembly,go,docker,wasm
canonical_url: https://medium.com/@didil/practice-your-go-webassembly-with-a-game-7195dabbfc44
---

#### Elevator Saga ported to Go WASM input

A few days ago, I wanted to take **Go WebAssembly** out for a spin, but I wasn’t sure what to build. Maybe a game ? but I didn’t really want to build a game from scratch. So I remembered the [**Elevator Saga**](https://play.elevatorsaga.com/), a programming game by Magnus Wolffelt I stumbled upon a few years ago: The goal is to transport people up and down building floors by controlling elevators, writing the rules in Javascript. What if I modified it to accept WebAssembly flavoured Go instead of JS !

Meet the [Go Wasm Elevator Saga](https://didil.github.io/gowasm-elevatorsaga/). The github repo is available [here](https://github.com/didil/gowasm-elevatorsaga).

![](https://cdn-images-1.medium.com/max/1024/1*6eQMikI5ylG_i1iCkoJLqA.png)<figcaption>Go Wasm Elevator Saga</figcaption>

### How it works

I’ve forked [the original repository](https://github.com/magwo/elevatorsaga) for the purposes of this exercise.

The original JS game is written as a Javascript App that takes the user input as text, runs a [js eval()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval) on it to transform it to a JS object and displays the results on the screen, moving the elevators accordingly.

In order to accept Go WASM as input we’ll need to compile it server-side. I’ve built a small **Go API service** that sits behind an Nginx reverse proxy, takes the user input, creates a .go source file, compiles it to WASM in a new docker **container** via the **Docker Go API** and returns the output binary to the browser.

#### Compiling the Go WASM

I’ve written a boilerplate **main.go** file that provides the setup required for the game to run and makes use of the functions **Init** and **Updated** that are provided by the user:

{% gist https://gist.github.com/didil/0003e3df513dcead73e2a820231a34e6 %}

The default/starter user input displayed in the game is the following:

{% gist https://gist.github.com/didil/53a7692d76291ed6389f695dd0016353 %}

The Init and Update functions above are the equivalents of the init and update functions required by the original game, as documented here [https://didil.github.io/gowasm-elevatorsaga/documentation.html#docs](https://didil.github.io/gowasm-elevatorsaga/documentation.html#docs)

#### The API Server

The API/build server takes care of 2 important steps:

- Copying the main.go file and the input.go file (from the HTTP post request) to a temp folder.
- Running a Docker container which will perform the build, passing the previous temp folder as input. The Docker run is done via the Docker API and not via the shell, allowing for safer error handling.

{% gist https://gist.github.com/didil/ceaf76ee2dc317577d85e4724268d1eb %}

#### Dockerfile

The Dockerfile in itself is very simple and equivalent to running the following command in the directory containing our source files:

```
GOARCH=wasm GOOS=js go build -o app.wasm .
```

{% gist https://gist.github.com/didil/fe725d30ba179cd8a00b0cecddecea60 %}

#### JS Integration

The actual JS/WASM integration is done in this JS file :

{% gist https://gist.github.com/didil/8cc6675ef8ac732b793252630345ebac %}

The JS code parses the server output, loads it into a WASM module and runs it.

#### Results

We run the game by clicking on Apply and … it works !

![](https://cdn-images-1.medium.com/max/1024/1*2z7VTv5MIaYs945n2ltfbA.gif)<figcaption>Go Wasm in action !</figcaption>

#### Compression

The Nginx reverse proxy performs GZIP compression on the WASM output, decreasing the size from ~1MB down to **~300KB**. I might revisit the results with [TinyGo](https://tinygo.org/) at some point as they promise much smaller binaries.

#### Server Side Caching

In the JS code above, you might have noticed the line:

```
let hash = SparkMD5.hash(json);
```

We hash the JSON input, which contains the input code and the compiler version (always go1.11.5 at the moment). We send that hash in the HTTP header _Code-Hash._ Nginx uses that header to cache WASM output. If you run an input that has already been compiled, the compiled WASM will return directly from the Nginx cache and the request will never touch the Go server, decreasing latency and saving resources. Client Side Caching could also be added in the future.

#### Conclusion

I hope you’ll have fun playing with Go WASM ! Here are a few resources to help you get started with the syntax:

- [https://github.com/golang/go/wiki/WebAssembly](https://github.com/golang/go/wiki/WebAssembly)
- [https://tutorialedge.net/golang/go-webassembly-tutorial/](https://tutorialedge.net/golang/go-webassembly-tutorial/)
- [https://www.aaron-powell.com/posts/2019-02-04-golang-wasm-1-introduction/](https://www.aaron-powell.com/posts/2019-02-04-golang-wasm-1-introduction/)
- [https://medium.freecodecamp.org/webassembly-with-golang-is-fun-b243c0e34f02](https://medium.freecodecamp.org/webassembly-with-golang-is-fun-b243c0e34f02)