<![CDATA[Mike Talks Tech]]>https://blog.flexicon.devRSS for NodeWed, 06 May 2026 15:53:38 GMT60<![CDATA[Gophers on the Web: Getting Started with Go and WebAssembly]]>https://blog.flexicon.dev/getting-started-with-go-and-webassemblyhttps://blog.flexicon.dev/getting-started-with-go-and-webassemblyWed, 17 Apr 2024 07:01:02 GMTHave you ever wanted to solve some specific problems in your web application, but JavaScript just wasn't spicy enough or you thought you could use more processing power?

Perhaps you're a fan of Web Development with Go and wanted to use it for more than just the backend?

Or maybe you've been hearing all the hubbub around WebAssembly (Wasm) and wanted to see what the big fuss was all about?

Well if you even remotely found yourself responding with an "eh, I guess" to any of the above: look no further. On this page you'll find a minimal, barebones, step-by-step guide of what it takes to get a Go program compiled down to a Wasm module, running in your browser and interacting with it using a simple HTML form.

What is WebAssembly?

To quote the Official Website:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

In the context of this post, you can think of it as a way for us to run code written in programming languages other than native web JavaScript in the browser.

The Goal for today

Let's keep things simple here.

We'll build a basic web page with a single input form. The form will take a number from the user and when submitted will display its square root.

About as simple as can be, and straightforward to achieve in vanilla JavaScript. However we're complicated individuals and we don't want to use JavaScripts math or parsing features here - all input parsing and calculations will happen in a Wasm module written in Go instead.

The Solution

Looking to jump straight into the solution? I respect your moxie. In that case check out the Git repo.
The key files to check are web/index.html to see how the Wasm module is hooked up to our HTML, and the Go Wasm source code itself under cmds/wasm/main.go.

🚨 Spoiler alert: here's a live version of the finished web page.

Otherwise, keep on reading and we'll break down the solution step-by-step.

A simple Wasm Module

The most minimal setup for a Go Wasm module doesn't differ in any way from a generic "Hello, World" program.

package main

import (
    "fmt"
)

func main() {
    fmt.Println("Go Wasm module instantiated!")
}

The secret sauce is all in how we compile the code from here on out.

In a regular Go program, we might do something like go build . , but when targeting Wasm we must specify more arguments and variables.

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

The GOOS variable tells the compiler what operating system we want our target binary to run on, and the GOARCH variables tells it what architecture should be used for the binary. This is also the standard way for cross compiling Go programs, for example to target darwin for macOS and arm64 for Apple silicon architecture.

Running the Wasm in a browser

First things first, we'll need a bit of JavaScript to run and instantiate our Go-based Wasm module in the browser - luckily the standard library provides this with every installation of Go, we must simply copy it over to our working directory.

cp "$(go env GOROOT)/misc/wasm/wasm_exec.js" .

Now we have a wasm_exec.js file which we can load in our browser - great, let's do that now.

<script src="wasm_exec.js"></script>

We can add the above snippet to the head of any HTML document where we want to execute Wasm. Let's create a skeleton document now.

<!DOCTYPE html>
<html>
  <head>
    <title>Using Go in the Browser</title>
    <script src="wasm_exec.js"></script>
  </head>
  <body></body>
</html>

Okay, so we've copied the code that will execute our Wasm module and loaded it in our HTML. Now we have to actually tell the browser to fetch, instantiate and run our app.wasm module. Add the following script tag below the one which loads wasm_exec.js in the head of the document.

<script>
  // Creates an instance of the Go wasm_exec class,
  // streams in the Wasm module using fetch
  // and finally runs it. 🚀
  const go = new Go();
  WebAssembly.instantiateStreaming(fetch('app.wasm'), go.importObject).then((result) => {
    go.run(result.instance);
  });
</script>

Let's test this out and see it come together in action. You should now be able to serve your index.html file along with the wasm_exec.js and app.wasm files using any preferred method. I personally like using gommand for quick demos like this one.

go install github.com/sno6/gommand@latest
# Now serve assets in your current directory
gommand 'http.Handle("/", http.FileServer(http.Dir("."))); fmt.Println(http.ListenAndServe(":8080", nil))'

The snippet runs a simple Go HTTP File Server based on your current working directory. Once it's running navigate to your web page (if using gommand http://localhost:8080/) and check your console - you should see the following:

🚀 Great success! Our Wasm module has been successfully loaded, and the standard output from our Go program has landed in our browser console.

Adding the Form and some Spice 🌶️

Currently our web page is empty and our Wasm module doesn't really do much - nothing to write home about in any case. Let's fix that.

Here's the markup for our form:

<main>
  <form id="sqrt-form">
    <input type="text" name="sqrt-num" id="sqrt-num" placeholder="Enter some number" required />
    <button type="submit">Calculate Square Root</button>
  </form>
  <div id="sqrt-answer"></div>
</main>

Save it and refresh the page to see... a bit more, but still not that much.

Let's quickly spice things up a notch by dropping in a little semantic CSS, courtesy of Pico ✨

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@picocss/pico@2/css/pico.classless.violet.min.css" />

... and adding a tiny bit of style to the body tag:

<body style="max-width: 900px; margin: 0 auto">

And - channeling my inner Emeril Lagasse - bam!

Nice - that's a little more presentable at least, and immediately matches our earlier mockup.

Extending the Wasm Module

Now that we have our form set up and markup thoroughly spiced, we can move on back to the actual Wasm code. So far, all it does is print a message to standard output and exits. In order to be able to have it calculate square roots for us, we'll need to do a few things:

  1. Export a function for the JavaScript runtime to call

  2. Keep the Go program running and waiting for calls to said function

We can achieve #2 fairly easily by adding a blocking channel receiver call on a perpetually empty channel.

func main() {
    fmt.Printf("Go Wasm module instantiated!\n")

    <-make(chan bool)
}

Cool. Now our program will actually wait around to receive calls. But what sort of calls is it listening for? Well at present: none. Let's change that.

func main() {
    fmt.Printf("Go Wasm module instantiated!\n")

    // 1
    js.Global().Set("GoSqrt", js.FuncOf(func(this js.Value, args []js.Value) any {
        if len(args) < 1 { // 2
            return math.NaN() // 3
        }

        return math.Sqrt(parseFloatJS(args[0])) // 4
    }))

    <-make(chan bool)
}

Now let's unpack a bit what exactly is happening here:

  1. We call the syscall/js.Global func, which allows us to use the standard library to interact with JavaScript's Global namespace (ie: the window object). In this particular case we Set (or declare) a new global function - named GoSqrt - which receives a reference to JavaScript's this scope for the function and a slice of js.Value arguments.

  2. We then do some initial argument validation, since our newly declared function requires one argument to be passed to it - the number for which we want to find a square root.

  3. If the function was called without any arguments, we return a NaN.

  4. If all is well, we call the standard library math.Sqrt func with the argument received from the browser after having parsed it.

Ah, I mentioned parsing. Well since JavaScript is not strongly typed, we can't really enforce what type of data gets passed to our function from the browser. What we can do is handle the types passed in Go, and in our case we can handle either a JavaScript number or string type. The js.Value struct provides some nice helpers to make this easier.

Here's how we do that:

// parseFloatJS returns a float64 from a js.Value, based on either a `number` or `string` js type. NaN otherwise.
func parseFloatJS(v js.Value) float64 {
    switch v.Type() {
    case js.TypeNumber:
        return v.Float()
    case js.TypeString:
        if f, err := strconv.ParseFloat(v.String(), 64); err == nil {
            return f
        }
    }
    return math.NaN()
}

The logic is fairly basic. We essentially return a float64 when the argument is a JavaScript number type, and if it is a string we use Go's standard strconv package to parse a float64 out of it and return the result if all went well. In all other cases we return NaN.

Wiring everything together

Phew, almost there. The last step is to wire it all up, with some standard DOM JavaScript. What we want to do here is listen to the form submit event, read the current value from our number input and pass it to our global GoSqrt function exported by our Wasm module. Finally we display the returned result from said function below our form.

So let's wrap this up by updating our script tag with the following:

function wireItAllUp() {
  const sqrtNumInput = document.getElementById('sqrt-num');
  const sqrtForm = document.getElementById('sqrt-form');
  const sqrtAnswerDiv = document.getElementById('sqrt-answer');

  sqrtForm.addEventListener('submit', function (e) {
    e.preventDefault();
    const value = sqrtNumInput.value;
    // This is the 👇 part where we call out to Wasm.
    const result = GoSqrt(value);

    sqrtAnswerDiv.innerHTML = `🤓 The square root of ${value} is ${result}.<br>So sayeth the Gopher.`;
  });
}

// This statement is unchanged apart from the wireItAllUp call.
WebAssembly.instantiateStreaming(fetch('app.wasm'), go.importObject).then((result) => {
  go.run(result.instance);
  wireItAllUp(); // 👈 This line is new.
});

Now if we save our changes (make sure to rebuild your app.wasm file after making any changes to it) and refresh the page, we should be able to finally use the form and calculate any and all square roots we could possibly want.

And there you have it - Go running in the browser and doing math. The possibilities from here are essentially endless.

Here's a link to the complete project as well as a live version to play around with.

What's Next?

To greatly reduce the size of your Wasm binary file, consider using TinyGo as your compiler. Also, explore more real-world uses for your Wasm module, like generating images or using third-party packages for heavy processing tasks. Stay tuned and follow the blog to get updates when new posts are published.

Further Reading

]]><![CDATA[Read Go HTTP Request body multiple times]]>https://blog.flexicon.dev/read-go-http-request-body-multiple-timeshttps://blog.flexicon.dev/read-go-http-request-body-multiple-timesTue, 15 Mar 2022 19:34:12 GMTI think we can all agree that writing HTTP servers in Go is an overall simple and pleasant affair. But what happens when we find ourselves needing to read the body of an incoming request multiple times? A common use case would be a middleware that needs to read and verify the request body before it can be processed further, or another that needs to log the request body while still allowing the body to be read later on.

The Problem

After reading once from the io.Reader implemented by the body field of Go http requests, it becomes impossible to read from it again. There is also no builtin way to simply "reset" the body as part of the interface.

The simplest solution

For the simplest solution, we simply need to make sure that every time we read through the request body, we read through it fully and then replace it with a new reader. Simple.

body, err := io.ReadAll(r.Body)
// Replace the body with a new reader after reading from the original
r.Body = io.NopCloser(bytes.NewBuffer(body))

We can even make use of an io.TeeReader and bytes.Buffer.

buf := bytes.Buffer{} // A Buffer is both a Reader and Writer
req.Body = io.TeeReader(req.Body, &buf)
// Do some body reading, then replace the body with the buffer
req.Body = &buf

Simple Reusable Reader implementation

Because Go's interfaces work via structural typing, we can very easily implement the io.Reader interface with a custom type as a drop-in replacement. Thus creating an io.Reader that can be "read from" an infinite number of times.

type reusableReader struct {
    io.Reader
    readBuf *bytes.Buffer
    backBuf *bytes.Buffer
}

func ReusableReader(r io.Reader) io.Reader {
    readBuf := bytes.Buffer{}
    readBuf.ReadFrom(r) // error handling ignored for brevity
    backBuf := bytes.Buffer{}

    return reusableReader{
        io.TeeReader(&readBuf, &backBuf),
        &readBuf,
        &backBuf,
    }
}

func (r reusableReader) Read(p []byte) (int, error) {
    n, err := r.Reader.Read(p)
    if err == io.EOF {
        r.reset()
    }
    return n, err
}

func (r reusableReader) reset() {
    io.Copy(r.readBuf, r.backBuf) // nolint: errcheck
}

Basic usage

A simple example of using our reusable reader with basically any io.Reader implementation.

func main() {
    text := "Lorem ipsum dolor sit amet"
    r := ReusableReader(strings.NewReader(text))

    readAndPrint(r)
    readAndPrint(r)
    readAndPrint(r)
}

func readAndPrint(r io.Reader) {
    b, _ := io.ReadAll(r)
    fmt.Printf("%s\n", string(b))
}

// "Lorem ipsum dolor sit amet"
// "Lorem ipsum dolor sit amet"
// "Lorem ipsum dolor sit amet"

Worth noting that if only dealing with strings.Readers or bytes.Readers, it is infinitely easier to simply seek back to the beginning of those readers since they implement the io.Seeker interface

r := strings.NewReader(text)
r.Seek(0, 0) // will effectively reset the reader back to the beginning

Request body usage

Things get more complicated when dealing with http.Request body fields, which don't implement the io.Seeker interface. In that case, for any http.Request we can easily use our reusable reader in place of its Body.

func handler(w http.ResponseWriter, r *http.Request) {
    r.Body = io.NopCloser(ReusableReader(r.Body))
    // Perform any reads however much we like from here on out
}

We needed to wrap our ReusableReader with an io.NopCloser in order to adhere to the io.ReadCloser interface. We could realistically simplify this case by implementing the io.Closer interface, just like the io.NopCloser does.

func (r ReusableReader) Close() error { return nil }

Which would allow the above example to be a tad simpler.

r.Body = ReusableReader(r.Body)

A more real-world example

Infinitely re-reading a static byte reader isn't all that exciting. So let's assume that we are building a web application and have created the following middleware for our request handlers, which both require the reading of the request body.

func logRequest(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        msg := fmt.Sprintf("%s %s", r.Method, r.URL.Path)

        if body, _ := io.ReadAll(r.Body); len(body) > 0 {
            msg += fmt.Sprintf(" Body: %s", string(body))
        }

        log.Print(msg)
        next.ServeHTTP(w, r)
    })
}

func verifyRequest(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        body, err := io.ReadAll(r.Body)
        // Perform some request verification here
        if err != nil || len(body) == 0 {
            log.Printf("%d: Request verification failed", http.StatusBadRequest)
            w.WriteHeader(http.StatusBadRequest)
            return
        }

        log.Printf("Request verified: %s", string(body))
        next.ServeHTTP(w, r)
    })
}

If used as is, then whichever of these middleware that we would run second would not be able to read the request body, since it would have already been read from by the first. This is where our reusable reader can come in handy, and we could simply wrap it's logic around a third middleware that should be ran first in the chain.

func reuseBody(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        r.Body = io.NopCloser(ReusableReader(r.Body))
        next.ServeHTTP(w, r)
    })
}

Now that we have all middleware in place, we can setup our http server and make use of the infinitely readable http.Request body.

Let's assume we have a handler called greet which will greet the user based on the request body payload - again needing to read from the request body after passing it through both of the other middleware already.

func main() {
    greetHandler := http.HandlerFunc(greet)

    mux := http.NewServeMux()
    mux.Handle("/greet", reuseBody(logRequest(verifyRequest(greetHandler))))

    fmt.Println("Listening on port http://localhost:9000/")
    log.Fatalln(http.ListenAndServe(":9000", mux))
}

Final thoughts and drawbacks

While this is all fine and dandy with the simple examples above, it's important to remember that this reusable reader is by nature not a very efficient implementation of the io.Reader interface; mainly because we require reading all of the data up front into a buffer. Which won't work well for anything large like files or larger streams of data.

Another issue with this approach is that we are assuming that everyone attempting to read from the reader knows and assumes that it is an instance of a ReusableReader. At which point it might be better/safer for middleware to simply read from the reader, process any data and replace the reader with a new one like mentioned before.

]]>