I’ve forked the original repository for the purposes of this exercise.
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.
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:
The default/starter user input displayed in the game is the following:
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
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.
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 .
The actual JS/WASM integration is done in this JS file :
The JS code parses the server output, loads it into a WASM module and runs it.
We run the game by clicking on Apply and … it works !