I kind of disagree with this article. With go its so easy to get started with http that most of the time you dont even need a framework. If you do, most good frameworks use the following function as a common basis:
func(http.ResponseWriter, *http.Request)
I started with barebones http, then used gorilla, and later started using negrioni.
Any new library with uses this function helps me.
So in the end: you dont need a framework, but libraries are nice.
Just looking at your fmt.Print link, you could be wrapping everything requiring a template in functions handling the html/template stuff, i.e. have code specifically interfacing templating for you that you can just pass a command "render this template". I had a lot of problems with working through templating and ended up with my own wrappers around html/template in Djinn(https://github.com/thrisp/djinn).
That's what this series of articles is doing. It starts with http.Handler and assemble libraries with minimal glue code to make things work without a lot of overhead.
I think most people that are using core net/http package utilities instead of a framework don't fall under the "deep understanding" category because of the ease and simplicity of said package.
Building a framework is useful for doing that, because you have to understand the routing mechanisms, the way statuses and headers are set within the net/http package, etc.
Comments
I kind of disagree with this article. With go its so easy to get started with http that most of the time you dont even need a framework. If you do, most good frameworks use the following function as a common basis:
I started with barebones http, then used gorilla, and later started using negrioni.Any new library with uses this function helps me.
So in the end: you dont need a framework, but libraries are nice.
Note: My api is a simple json based rest service.
I created a small starter Go Web Server from a website that I'm building:
GitHub: https://github.com/melling/GoWebServer
I'm not sure that I like embedding html in fmt.Print() methods, along with templates. A lot of my page handlers look something like this:
https://github.com/melling/GoWebServer/blob/master/src/webse...
My site is about 4000-5000 lines of Go, with a bit of "repeating myself". I'd like to hear from devs who've built larger sites.
Btw, here's my site:
http://thespanishsite.com
And the usually "hidden" admin pages where I've done most of my work:
http://thespanishsite.com/admin/summary?language=chinese&pic...
Just looking at your fmt.Print link, you could be wrapping everything requiring a template in functions handling the html/template stuff, i.e. have code specifically interfacing templating for you that you can just pass a command "render this template". I had a lot of problems with working through templating and ended up with my own wrappers around html/template in Djinn(https://github.com/thrisp/djinn).
This dotGo talk[0] about dependencies is spot on. Composition makes you reap all the benefits.
[0]: https://www.youtube.com/watch?v=yi5A3cK1LNA&list=PLMW8Xq7bXr...
That's what this series of articles is doing. It starts with http.Handler and assemble libraries with minimal glue code to make things work without a lot of overhead.
I agree. Those learning path is best for a deep understanding of how go works in the inside.
I think most people that are using core net/http package utilities instead of a framework don't fall under the "deep understanding" category because of the ease and simplicity of said package.
Building a framework is useful for doing that, because you have to understand the routing mechanisms, the way statuses and headers are set within the net/http package, etc.