There are quite a few different web frameworks for Go, as well as just the built in `net/http`. Has any one package emerged as more common or standard than others?
The common reply in the Go community is "don't use a framework" or "roll your own".
The idea is that small packages suited to individual tasks are a better solution than a large framework package that includes more than you need, or tried to for your use case into a shared, common use case.
IMO, frameworks are great for rapid prototyping, but in Go and it's explicit programming style, most devs prefer to build most by have and only import a minimal number of packages for specific tasks.
Some common helpers are nice though, not sure that constitutes a framework but it definitely saves time not having to rewrite response compression and logging.
Nobody has mentioned beego [1]. You can write a decent web-application using core Golang language. Yet, coding large applications require many features, like session handling, db connection, and so on. Instead of composing these from independent sources, you can use Beego which comes bundled with all of these.
If you are aware of Python ecosystem Beego is like Django (though Beego doesn't have an admin module).
I have been using Beego for couple of years now for my personal projects. I'm happy with it. It has almost all the features required for a web-application framework. It has good documentation too.
Just yesterday I released a side-project sheet2buffer[2], coded in Beego as backend and React as front-end.
If you are interested, I also wrote an introductory post about Beego[3].
I started a project about a year ago and I specifically wanted to answer this question. As a result, I wrote that project in revel.
Ultimately I don't hate revel and the result is an operational system today. I don't exactly regret the decision to use revel, but I also think that revel ultimately didn't bring many useful things to the party. I do know I'd have a better, more extensible easier to understand application if I had not used revel. I do know that if I was just using standard net/http I would have developed things faster. I found myself more often fighting against the framework to bend it to my will than benefitting from it.
All that said, I don't think I would have the confidence that "just use net/http" is the correct answer had I not done a project in revel.
I did a few projects before and after and in-between the revel project, while still actively developing and maintaining the revel project. Ultimately, I now find myself dreading working on the revel project to the point where, when I have time to spare, I'm much more likely to work on one of the non-revel projects.
I dabbled with Go some years ago, and I was excited to try it again because I like statically typed languages and the simplicity of Go.
However, the package management story was insane. I had really hard time with that. Fortunately they are acknowledging the problems and fixing them.
Also, I kept missing Rust-style error handling. I've been programming in Rust extensively for a few years, and I thought Go might provide benefits of being "a simpler (garbage-collected) Rust". However, I keep longing some nice things from Rust.
Revel was... Ok. The fact that it builds the code while it's running is nice for rapid prototyping, but it was also really hard to fix if/when it didn't work. ( https://github.com/revel/revel/issues/1349 )
I found the default template engine to be a bit lackluster – template inheritance is the basic pattern I'd like to see everywhere as the default, but it didn't support that.
The project is still in an early phase so it's hard to say more than that.
I write my own middlewares for logging, auth, etc. Use viper for configuration, gorm for an ORM, and for anything more complicated, accept that you’re about to learn a whole lot about it because you’re gonna be writing it yourself.
To each their own, but I personally prefer the lego-building block-approach instead of the kitchen-sink approach of bigger frameworks. In Go at least, this scales quite nicely with your code IMO.
I generally just stick to net/http. In both small projects and large enterprise-y projects it's served well. I think most Go devs are roughly of similar opinion at this point.
gin[1] is a popular off-the-shelf solution that provides a lot of functionality for you. But as everdev said, it's pretty normal to gradually build up your own stack using the stdlib and possibly some smaller, more focused packages like httprouter[2] and the gorilla toolkit[3].
I actually have learned a lot about HTTP/HTTPS servers by working on a lower level and building up my stack! I recommend just starting with the stdlib and importing 3rd party code where you feel yourself limited by it. The first thing people probably adopt is a more expressive router.
While I'd agree that net/http is very capable, it still comes with a variety of gotchas when doing timeouts, logging, routing, etc. I think gin[1] is a good bet for jumping into building something without having to dive into doing a lot of http.Server research.
Also love Gin - I've used this for maybe a dozen different projects. Sometimes I use the stdlib but when I do I usually end up trying to make an API like Gin. Gin just makes things so much faster to write good looking and well-performing code with their contexts and simple API.
My favorite thing about Gin: its README has 90% of what you need to know, with refined examples. I love when README's are so expressive, especially when Gitlab/Github/Bitbucket make the README the front page. Also, the README comes with the code when you clone so you can easily refer to it offline (I realize you could generate Godocs but I always forget the command to do this, and Godocs don't often have nice examples).
I'll also point out that Gin has an excellent collection of contributed middleware [1].
I would like to mention aah framework [1], Documentation [2], Examples [3]; have a look and see. Does it match with your direction and project needs. I'm looking forward to your candid feedback.
Personally I would say it depends on your project needs, timeline, etc. Whether you're gonna use framework or roll your own.
My suggestion is to take your time to evaluate the frameworks and select the one which satisfy you the most. Generally none-of-the-framework would cover 100% of project needs; including aah.
I've used Gorilla http://www.gorillatoolkit.org for 4+ years and I'm happy with it. It follows the signatures of net/http and routing is easier than regex.
I'm surprised there isn't more about Buffalo in this thread. It's creator (Mark Bates) has stated inspiration from the rails world, but has focused on building Buffalo to be very flexible.
It provides a nice boiler plate for the modern web app and pulls together a lot of the single packages mentioned here so you don't have to worry about wiring things together.
I've built a few small apps with it and thoroughly enjoyed the dev process.
I really like chi[0] - I think it strikes the right balance of being small and understandable, but also solving common problems (e.g. nested routes, URL parameters, etc.). It also uses standard Go conventions, so it's very interoperable and would be easy to migrate away from, if necessary.
It's a net/http replacement that is close to x10 in performance -- however it is not a drop in replacement and you should avoid it unless you really actually need the rps.
That's pretty much the opposite of a web framework.
You have to use a vendoring tool like Glide[1] for now, but Go is actively testing official vendoring support with vgo[2], where you use git tags for versions.
"Go kit is a programming toolkit for building microservices (or elegant monoliths) in Go. We solve common problems in distributed systems and application architecture so you can focus on delivering business value."
However, Go ecosystem is starting to look interesting library-wise, as long as your project doesn't involve enterprise integration with legacy XML services or SOAP, because Go sucks at mostly anything XML.
For templating I use Jet because the standard templating library is too basic for professional use https://github.com/CloudyKit/jet .
If you don't mind. I would like to request you to have a look aah framework [1]? and share your candid feedback. I'm interested in your viewpoint. I'm the author of aah.
The author of this framework, who calls himself Kataras, is very unethical.
He fell into a big controversy with the management of his repositories, stealing several chunks of code from other popular projects without giving credits to their respective authors, and then using them to write benchmarks to make his own project look better than it is. He also spent several months creating bots to upvote his articles on different news aggregators and star his repositories to increase visibility in the GitHub Trending page. He also created several accounts in different websites (mostly Reddit) to act as a supporter of himself. The last time I heard about him, he had forked his own repositories multiple times to re-brand Iris with other names, hoping that people wouldn't notice, specially people who are just starting using Go.
I've been using Go for quite a long time (since before the 1.0 release); I've never heard of Iris before.
It looks interesting, but appears to be an "all in" approach. I gather that folks who like Django may like this a lot, but for me personally it rubs me the wrong way.
This may be due to my "anti-framework" mindset, but in my experience a lot of other Go developers have this same mindset. YMMV
I started with a more "batteries included" framework. There were too many impedance mismatches between the framework and other libraries. Having to whittle almost every 3rd-party library to fit within the framework was not worth the effort.
web frameworks aside what's really missing an ORM. i'll get excoriated for even suggesting that i shouldn't just use sqlx or whatever but using django/python makes me hate using go for web backends.
The idea is that small packages suited to individual tasks are a better solution than a large framework package that includes more than you need, or tried to for your use case into a shared, common use case.
IMO, frameworks are great for rapid prototyping, but in Go and it's explicit programming style, most devs prefer to build most by have and only import a minimal number of packages for specific tasks.