3

Every request to my application should use some middleware. Using the Negroni docs I have implemented it like so:

func MyMiddleware(rw http.ResponseWriter, r *http.Request, next http.HandlerFunc) {
  // do some stuff before
  next(rw, r)
}

and elsewhere I use:

n.Use(negroni.HandlerFunc(MyMiddleware))

However, the middleware needs to receive an extra argument and I'm not sure how to build this in. At the moment I'm just setting the value as a global variable to make it available but I'm sure there's a more elegant way?

I would like to be able to do something like this:

n.Use(negroni.HandlerFunc(MyMiddleware(val)))
tommyd456
  • 10,443
  • 26
  • 89
  • 163

1 Answers1

5

The best way would be to encapsulate your middleware as a struct that holds its state, not just a stateless function. (You could also wrap it as a closure but a struct is cleaner IMO):

type MyMiddleware struct {
    someval string
}

func NewMyMiddleware(someval string) *MyMiddleware {
    return &MyMiddleware{
       someval: someval,
    }
}


func (m *MyMiddleware) ServeHTTP(w http.ResponseWriter, r *http.Request, next http.HandlerFunc) {

    // Do Something with someval
    fmt.Println(m.someval)

    next(w, req)
}

and initializing it is simply:

n.Use(NewMyMiddleware("foo"))

EDIT: Perhaps a closure would actually be simple:

 someval := foo

 n.Use(negroni.HandlerFunc(func(rw http.ResponseWriter, r *http.Request, next http.HandlerFunc) {
   // Do Something with someval
   fmt.Println(someval)

   next(w, req)
}))

Or you could have a function that returns a middleware function:

func NewMiddleware(someval string) negroni.HandlerFunc {
     return negroni.HandlerFunc(func(rw http.ResponseWriter, r *http.Request, next http.HandlerFunc) {
       // Do Something with someval
       fmt.Println(someval)

       next(w, req)
    })
}

and then

n.Use(NewMiddleware("foo"))
Not_a_Golfer
  • 47,012
  • 14
  • 126
  • 92
  • Hmmm - seem like overkill to me - might stick with global variable to be honest. – tommyd456 Aug 26 '15 at 20:11
  • 1
    @tommyd456 until you need more than one stateful variable, or you need more than one instance of your middleware. If neither's the case, then a closure would be enough. I'll add it to my answer. – Not_a_Golfer Aug 26 '15 at 20:13
  • I like the closure approach - I gave this a go myself and was almost there. Cheers for this. Gonna give it a go in the morning! – tommyd456 Aug 26 '15 at 20:19
  • @tommyd456 If you use a global make sure you don't have data races (try the [Go race detector](https://blog.golang.org/race-detector)). You'll probably find that adding synchronization to remove data races is (often/usually) more work. – Dave C Aug 26 '15 at 20:38
  • 1
    @DaveC right, unless it's some immutable state like a configuration struct you initialize in main() or something. Usually I use closures if there's little persistent state, and structs if there is, especially if it's mutable. – Not_a_Golfer Aug 26 '15 at 20:48