Gin compatibility layer per route middlewares

[evilenzo]

Problem

As stated in #241 gin compatibility layer currently does not support per route middlewares. option.Middleware applies no middlewares to gin engine.

Points of interest

• Apply http middlewares (default ones for fuego func (http.Handler) http.Handler) to gin engine using wrapping (easy task)
• Apply gin middlewares to gin engine (func (c gin.Context)) (bit harder, description below)
• Global middlewares for gin? (very hard, have no ideas currently)

Solution

We don't introduce any API breaking changes, still store middlewares everywhere as func (http.Handler) http.Handler and convert them to gin ones when registering routes. Major problem is wrapping. Convert http middleware to gin is not a problem. But we also want to pass gin middlewares and it's a problem since we store all middlewares as http ones. So we have to convert one gin middleware twice. One when we pass it to storage using option, second when we apply it to gin. So idk if this way is reasonable cause converting gin middleware to http one is a bit runtime-consuming

[evilenzo]

@EwenQuim @dylanhitt any thoughts/suggestions?

[evilenzo]

Maybe we should store middlewares everywhere as any and only when we apply routes we convert them (not by wrapping but by type conversion v, ok := middlewares.(func (http.Handler) http.Handler)? With this way we also not breaking API and get no runtime overhead. If conversion fails we panic on start time. Is this way more reasonable than double conversion one?

[dylanhitt]

My thoughts on this is that it would be nice to have a solution that could allow for the use of both the gin default middleware and fuegos default middleware.