@danielgtaylor Hi, theoretically, what could this be merged if documentation will be added? Or architecturally, do you want to change something or perhaps generally disagree with this new feature?

@Insei hi, thanks for pinging about this and sorry for the delayed response. I think the generic middleware concept is good and am in favor of adding it so long as it remains optional and you can continue to use router-specific middleware if you want/need to.

The one hesitation I have is your proposed interface for it, where each middleware is called one after the other without any ability to modify the context. This makes e.g. compression middlewares which require replacing the reader/writer impossible at the moment. I wanted to put together an alternative for you but haven't had the time, so I'll just type out some thoughts here.

I think each middleware should be chained like you see with other Go routers that support middleware (or stuff like Express in Node land). E.g. each middleware could be a func(ctx huma.Context, next func(huma.Context)). The advantage is that a compression middleware is then something like:

type CompressionContext struct {
  huma.Context
}

func NewCompressionContext(ctx huma.Context) *CompressionContext {
  return &CompressionContext{ctx}
}

func (c *CompressionContext) BodyWriter() io.Writer {
  return gzip.NewWriter(c.Context.BodyWriter())
}

func CompressionMiddleware(ctx huma.Context, next func(huma.Context)) {
  newCtx := NewCompressionContext(ctx)
  next(newCtx)
}

I also don't think the API argument should be necessary, as this can be handled at middleware instantiation time, for example:

type MyMiddleware struct {
  api huma.API
}

func NewMyMiddleware(api huma.API) *MyMiddleware {
  return &MyMiddleware{api}
}

func (m *MyMiddleware) Handle(ctx huma.Context, next func(huma.Context)) {
  // I don't do anything
  next(ctx)
}

// Usage example
api := // ...
m := NewMyMiddleware(api)
huma.UseMiddleware(api, m.Handle)

Also on that note, why not register middleware with a specific API like api.UseMiddleware(m.Handle) - why make it a global func?

Anyway hopefully this helps, let me know what you think and I'll try to come up with a better example of what I mean when I get a chance. For now you can probably look at a few other Go implementations of middleware to see how they code it.

@danielgtaylor Thanks for response!

I think each middleware should be chained like you see with other Go routers that support middleware (or stuff like Express in Node land). E.g. each middleware could be a func(ctx huma.Context, next func(huma.Context)). The advantage is that a compression middleware is then something like:

You're definitely right, and that's what I'll do. I just wanted to ask in this PR if there are any contradictions in implementing middleware specifically for HUMA.

I also don't think the API argument should be necessary, as this can be handled at middleware instantiation time, for example:

Theoretically, it is possible to use several instances of the huma.API at the same time, but with diff. set of middlewares; of course, the probability of this is not great, but it does exist. But if we will have api.UseMiddleware, this problem will be resolved.

Also on that note, why not register middleware with a specific API like api.UseMiddleware(m.Handle) - why make it a global func?

I was just watching how the Register method was made :)

@danielgtaylor I made middleware the same way as in chi =) and replace UseMiddleware to API interface.

#134