The beauty of interfaces in Go - Part 1

I’ve wondered, what’s soo great about interfaces in go just because it implements interfaces implicitly?

Doesn’t it simply omit the boilerplate of writing class foo extends interface bar ?
I couldn’t have been more wrong. It is only after we see the difficulties of implementing a good interface in other languages that we appreciate how first-class the interfaces in Go are. Let’s dig deep right into it.

If you’re atleast familiar with Go somewhat it is impertient for you to encounter io.Reader, io.Writer,, http.ResponseWriter, or http.HandlerFunc. Let’s dive into each and every single one of them to see how easy go makes our lives with its interfaces.

Today we’re gonna uncover what happends underneath the function:

http.HandleFunc( ‘/foo’, bar(w http.ResponseWriter, r *Request)

and how it implements interface to achieve what it does.

1. What exactly is http.HandleFunc in Go? and how does http.HandlerFunc and ServeHTTP come into play?

it’s nothing more than type HandlerFunc func(w ResponseWriter, r Request) declared inside net/http package. Esentially it’s a type declaration of a function with func(w http.ResponseWriter, r http.Request) signature.
It has a method called ServeHTTP.

type HandlerFunc func(w ResponseWriter, r Request)
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
    f(w, r)
}

what makes this wonderful is that inside server it expects a http.Handler for our route.

type Handler interface {
    ServeHTTP(w ResponseWriter, r *Request)
}

Now that we’ve seen what a Handler and a HandlerFunc are let’s see what happends when we give a handler function to the http.HandleFunc function.

http.HandleFunc("/foo", bar(w http.ResponseWriter, r *http.Request))

Essentially what you need to understand is, Go doesn’t run the function directly when it matches the pattern.

Then what does it do? how does it work?
What it essentially does is,

1. take the function bar, type cast it to http.HandlerFunc, so that SeverHTTP method is available at the disposal of function bar. As such bar is effectively implies interface Handler, since it satisfies the condition of having a ServeHTTP(w http.ResponseWriter, r *http.Request) method.

2. Now when a request comes at /foo this handler’s ServeHTTP method is executed.

[read the net/http package for more details]

What many programmers miss is that - there is no such thing as handler functions for go. Go only ever cared about the Handler interface and it’s method ServeHTTP.
http.HandleFunc function was simply a sugar coated way of not creating a struct that satisfied this handler interface with the ServerHTTP method and running it via http.Handle function.

Since it has been established it is the ServeHTTP method that is executed and not the function itself, it gives a lot of leeway on how we want our handler to be executed and how.
It gives us the freedom to implement however we want with whatever complexities we want. This is what frameworks like Gin, gorila/mux, takes advantage of to make their framework underneath.

Essentially - do whatever they want with it, and just give our something which can have ServeHTTP method that can run after being attached to the hashmap that stores the pattern and the handler for our *ServeMux that runs on a port.

What it entails is that, if in the future, you want to make your own framework, you can just do it by making sure there exists a SevrveMux* attached to a port and all the routes patterns are attached to the patterns field of that ServeMux, and make the implementation of the handler functions in your framework however you want, but to simply make sure it implements ServeHTTP method for it to work with the net/http framework.

I suggest you just go and try building one rudimentary framework in Go.

I know it might not make sense as of now. But make sure to stay tuned on what comes on io.Reader/io.Writer . That’s where the real beauty of interface starts to shine for go.