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
- 2000: C#
- 2004: Web 2.0
- November 2009: Go
Well, being Google, they thought they may want to use this to build web applications so in steps the
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.
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.
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.