« previous

y u no framework

y u no framework

This is the most common question that I receive about building web applications in Go is:

“What framework should I use to build my API?”

To really explain this to you, it has to do with experience, problems running Go in production and lastly, a little history lesson. Why the history lesson? What does that have to do with frameworks? If we don’t learn our history, we are doomed to repeat it.

A little bit of history…

Well, a long time ago before the internet, man created programming languages so the web and http was not taken into consideration. Let’s look at a little timeline.

  • 1972: C
  • 1983: C++
  • February - 1991: Python
  • AUGUST - 1991: Internet goes Live
  • 1995: Ruby
  • May 1995: Javascript and Java
  • 2000: C#
  • 2004: Web 2.0
  • November 2009: Go

I only included major languages used in the web thus far, so if I forgot your language, I am sorry. So as you can see from my little list, that most languages existed before the web took off and before web 2.0 except for Go. Since Google is the driving force behind Web 2.0 and the creator the Go, I would have been shocked if there was no correlation between the 2.0. I included Javascript for the sake of Node.js.

What can we deduce from this? Well, since we are use to using languages prior to the internet, we usually need some kind of “framework” to help build web applications. Ruby has Sinatra and Rails. Python has Django, Flask and Tornado. C# has .NET. Javascript or Node has Express. So it’s safe to assume to apply this Go, right? Nope.

Go’s Design

Well, being Google, they thought they may want to use this to build web applications so in steps the net/http package. It was designed to not need a framework. It has some things missing like a router with parameters or context package (which is changing in 1.7). So rather then assuming, we need a whole framework to address our situation, we should attack each problem individually. Go has made importing packages very easy. You will even see importing packages as web url as well (i.e. github.com/apriendeau/some-package).

Disadvantage to a framework? In this case, yes. It can lock you into patterns that are not idiomatic or troublesome to solving your problem. It can lock you into features like routing, context, recovery and logging when you find that you will need to change to suit your needs.

Challenge

Try to build your application with net/http and some extra packages. This is a challenge that I pose to everyone. There are several posts on how to use middleware and chaining with Alice. I know that I have written one that also addressing using HTTPRouter. If you are in the one percent that net/http can’t solve your problem then use a framework. Some might find it easier but most of the time, you find that core has done a beautiful job designing the language.

comments powered by Disqus