A Series-Of-Tubes 2.0

A major milestone for the internet, Web 2.0 began it’s rise toward popularity sometime around 2004. This represented a shift from static web pages to dynamic, user-generated, social content. This also represented a shift in software development to a strong focus on building publicly available RESTful HTTP API’s. What does all this have to do with using a web framework? Stick with me…

The Python programming language was introduced in February 1991, Ruby in 1995. The world wide web(in it’s infancy) was introduced in August 1991. This means that the core of Python & Ruby were built in a time where the internet, and certainly modern HTTP API’s were not a problem software engineers were solving. As the internet progressed and the need to build API’s presented itself it was up to the communities of those languages to build frameworks on top of the standard libraries to solve new problems the languages themselves were never designed to solve. And build frameworks they did! Neat, but what about Go?

Here We Go!

Go was introduced in 2009, well into the modern era of API development. The simple fact is the Go language WAS designed to solve the problem of building HTTP API’s. Instead of the community needing to build framework’s (though many still are) we have a standard library package (net/http) that already does what we stated frameworks are for (abstracting boilerplate). If you’ve got a keen memory you might remember the second part of Jeff Knupp’s quote:

Just how much is hidden depends on the framework.

So where does net/http fall in this range of abstraction. In my opinion it falls on the minimal end (similar to the level of Flask and Sinatra). It provides abstraction of the very basic thing’s you’ll need to construct an API. This leaves some developers (fans of Django or Rails) with a desire for more abstraction. Does this mean that there is room for frameworks in the Go ecosystem? Maybe. However, I’d suggest you consider a take-only-what-you-need approach. By this I mean select a single-purpose library to solve the problems you don’t find solutions for in the standard library.

Do you need structured logging? Take a look at Logrus or Zap. How about a database layer? You might want to reach for database/sql, sqlx, or Gorm. Is the standard mux/router not up to par? Give httprouter or gorilla/mux a try. There are plenty of single-purpose, pluggable solutions to individual problems you may need to solve. Many are compatible with the standard library (always a good thing). Taking this approach you can often avoid the overhead of large frameworks providing additional features/abstractions you don’t need.