-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could gin use a more advanced router ? #1730
Comments
Seconded, I believe that people can accept the flexibility with some lost. |
One of the issues is when using middleware such as:
Intentionally this should:
However this will complain with First registered seems to be a pretty solid way to go and would fix this routing example. |
Same problem in my project Solitudes
route conflict |
First registered seems reasonable. The echo folks have a fixed ordering which IMO isn't bad either:
|
This issue is big enough that I would never recommend gin for any serious project. The fact that you have to rename your routes because of this conflict is insanely annoying and the team constantly has to create weird routes to make everything work. How useful is this route optimization really? Typical REST frameworks are going to hit database limits before httprouter becomes a bottleneck. I regret using gin and you get trapped at the beginning because there isn't a big red notice saying "gin does not support classic REST apis because of its insane httprouter implementation" |
trap in same problem when trying to rewrite existing project with gin |
I strongly agree at least with this part, as long as it remains unfixed I'm stuck with this issue and since in some project scenarios routes are already defined by spec/requirement and cannot be changed on development cycles I'll have to work around this on the traffic layer so I can still use the original routes as intended |
Is there a proper workaround for this, other than writing a manual routing function ? |
This seriously needs to be addressed. Having to write convoluted middlewares to make any serious (not to mention conventional) application suggests a troubling oversight in design. |
The router conflict broke my Restful tourist in my company. I really need a replace method in the project (even if only a workaround) Do anyone has an idea? THX. |
@csvwolf you can embed a
Related issue: |
@xuyang2 Thanks, I have the same idea and is doing wrapper like that: apis := utils.Route{}
apis.Init(e, "/api/v1")
regions := apis.Group("/regions")
{
// They are gin middleware
regions.GET("", getAllRegions)
regions.POST("/groups", addRegionGroup)
regions.GET("/groups", getAllRegionGroups)
}
languages := apis.Group("/languages")
{
languages.GET("", getLanguages)
}
banners := apis.Group("/banners")
{
banners.GET("", getBanners)
banners.GET("/{id}", getBanner)
banners.POST("", createBanner)
banners.PUT("/{id}", updateBanner)
banners.DELETE("/{id}", deleteBanner)
}
apis.Fin() Just use mux for router but can use anything else in gin and of course, the minimum changes for code, only for the router params |
Sorry to interrupt. Any plans on this issue? This is a showstopper to our project. |
Hei,
This issue is related to #205 #388 #1065 #1162 #1301.
Gin uses httprouter, which is not very helpful when using wildcards and a few routes. The related issue julienschmidt/httprouter#73 has been closed 4 years ago. It's by design and the suggestions are to do manual routing by hand, which I think is not acceptable for a cool framework.
Therefore, gin could perhaps switch to a more advanced router. "First registered" works well with Express for example.
The text was updated successfully, but these errors were encountered: