And yet I far prefer all of them over an interface{} solution. Works so much better. But the files are just so ugly, and changing them is rather hard.
Worst of it all, I've been thinking about generating other pieces of the code. For instance, I hate the http handlers and structure surrounding them being the same thing all the time.
Http handlers = decode and basic argument validation, then authentication and CSRF protection, and then conversion (to be done ad-hoc because no types in http parameters), some using strconv, some using json encoding, all with "error handling" (essentially if error then bailout 502), followed by calling the actual method. All of them are the same (save for small bugs due to me not paying attention).
I'm thinking of replacing it with generated code.
Re handlers, you really don't have to use the http handler. I use one which accepts a context, and returns an error (for rendering), which simplifies the boilerplate somewhat as errors are rendered by the router. I'd look into using your own interfaces before generating standard http handlers.
The other thing to bear in mind is that if you try to make things all implicit rather than explicit in order to avoid repetition, it's very easy to be unaware of what's happening behind the scenes (auto-auth, or auto-render as in rails), and get stuck when you want to do something off the beaten path. I rather like Go's more verbose but very explicit style. It's a trade-off.
Auth, CSRF, parameter parsing should definitely be in a separate pkg you're using, not repeated each time IMO, so there should be minimal boilerplate for those.
Using text template is a really nice way to generate http handlers if you typically set up resources in a similar way, so I'd definitely recommend trying that out. I haven't looked into go generate as that came out after I started this approach.
The approach I take is to generate actions with all the normal code in them as scaffold (for CRUD actions) - so for each one auth, then setup, then business logic, then render, and then edit those as necessary, as often as an app grows each action diverges from the standard (say it doesn't do auth, or processes parameters differently etc). This is easy, explicit, and very clear when returning to code after 6 months at the cost of some verbosity.
