You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A Routing Group like interface from the dimfeld/httptreemux package used for kami's router is not exposed on the kami.Mux object. This would simplify larger projects when building URLs.
For example, if I wanted to setup my application with multiple API versions, I could have my code split between server/endpoint logic as follows:
package server - > holds a simple main.go that imports packages from various API imports, sets up a user auth middleware on the context
package api/foo/v1 -> has a LoadRoutes(ctx context.Context, prefix *kami.Mux) function that adds its own group of routes building on the prefix supplied by the prefix router passed in. (e.g. if the group router that was passed in is for '/api/', this adds the group of routes for '/v1/' which when added to the group translates to '/api/v1')
package api/foo/v2 -> has a LoadRoutes(ctx context.Context, prefix *kami.Mux) that is the same as v1 except adds the group of routes for v2
A quick (not thought out) example:
main.go:
package server
import (
//..." api/foo/v1"" api/foo/v2""github.com/guregu/kami"
)
funcinit() {
// Setup Auth middleware and other thingskami.Use('/', Login)
// ... Other things...group:= kami.NewGroup('/api')
v1.LoadRoutes(kami.Context, group)
v2.LoadRoutes(kami.Context, group)
}
Hello, could you be more specific about how groups would work? Unfortunately we can't merge arbitrary contexts, so it might be impossible to implement.
I can make it easier to use different contexts. I think I will add a way to copy URL params from one context to another. Right now the lack of such a function makes it difficult to use middleware that completely replaces the context.
For routes like:
/api/v1/...
/api/v2/...
You don't really need groups to separate them. You can add common middleware with kami.Use("/api/", mw). Then you can add v1 middleware like kami.Use("/api/v1/", mw) and v2 middleware like kami.Use("/api/v2/", mw). You can add multiple middleware functions to the same route.
I'll also get #21 taken care of so it's easier to run kami from a kami.Mux.
A Routing Group like interface from the dimfeld/httptreemux package used for kami's router is not exposed on the
kami.Mux
object. This would simplify larger projects when building URLs.For example, if I wanted to setup my application with multiple API versions, I could have my code split between server/endpoint logic as follows:
package server - > holds a simple main.go that imports packages from various API imports, sets up a user auth middleware on the context
package api/foo/v1 -> has a
LoadRoutes(ctx context.Context, prefix *kami.Mux)
function that adds its own group of routes building on the prefix supplied by theprefix
router passed in. (e.g. if the group router that was passed in is for '/api/', this adds the group of routes for '/v1/' which when added to the group translates to '/api/v1')package api/foo/v2 -> has a
LoadRoutes(ctx context.Context, prefix *kami.Mux)
that is the same as v1 except adds the group of routes for v2A quick (not thought out) example:
main.go:
api_v1.go:
api_v2.go:
I'm interested to hear thoughts on this and see whether or not this feature could be added to kami!
The text was updated successfully, but these errors were encountered: