Update Middleware function to be less brittle, using the builder or functional options pattern, as described by John in #141:
This is the kind of function that will probably grow over time, with new parameters. This makes the API brittle, since you wind up breaking existing clients when you change the function's signature.
If we add more parameters here, it would probably be better to move to either the builder pattern or the functional options pattern described by https://golang.cafe/blog/golang-functional-options-pattern.html.
An really trivial example:
type TraceOption func(*traceHandlerBuilder)
type traceHandlerBuilder {
// whatever fields are necessary to build the handler
}
func (builder traceHandlerBuilder) build() func(http.Handler) http.Handler { ... }
func EchoFirstTraceNodeInfo(opts ...TraceOption) func(http.Handler) http.Handler {
var builder traceHandlerBuilder
for _, o := range opts {
o(&builder)
}
return o.build()
}
Alternatively, you can expose the builder as part of your API. gorilla/mux takes this approach. The choice of which is really more about what will be more stable for a client.
Update Middleware function to be less brittle, using the builder or functional options pattern, as described by John in #141: