[topicseed]

I've always have my handlers individually set as a struct each with a method to handle the route/request.

type CreateUser struct {

   store  storage.Store

   cache  caching.Cache

   logger logging.Logger

   pub    events.Publisher

   // etc

}

func (op CreateUser) ServeHTTP(ctx, req, rw) {}

// or if you have custom handlers

func (op CreateUser) ServeHTTP(ctx, input) (output, error) {}

And in my main.go, or where I set up my dependencies, I create each operation, passing it its specific dependencies. I love that because I can keep all the helper methods for that specific operation/handler on that specific struct as private methods.

It does get tedious when you have one operation needing another, as you might start passing these around or you extract that into its own package/service.

[lelandbatey]

This is kinda missing the point; each handler needs a lot of deps to do it's job, and the most obvious place to put them is in the parameters of the function. That is what I want. I do not want more indirection for aesthetics; I want clarity, even if it's brutal clarity.

Whether all the deps are in the method receiver (the parent struct) or in a struct that's a param; it's all just more indirection to hide all the "stuff" that we need cause we think it's ugly. I dream of a world where we don't do that.

[topicseed]

You do have to instantiate that struct, and you can do it with.... a beautiful NewCreateUser(dep1, dep2, dep3, ..., dep20) *CreateUser {...}. This is essentially what he recommends with his "func newMiddleware() func(h http.Handler) http.Handler".

[lelandbatey]

I'm pointing out that this is basically "passing all the deps at once" with extra steps but no functional benefit; they are at best aesthetic, at worst confusing.

I'd like a world that sacrifices a bit of aesthetics in order to erase ambiguity or confusion. So instead of putting your deps in a struct that's a param, or putting your deps in a parent closure, I'd like to put them in the function params.

Though I will admit that if I had to choose, I'd use (and have used) the closure approach most often.