General middleware execution order about gorouter HOT 7 CLOSED

yes, i am using it in my project and besides that i believe native implementation should be default one always available. So in our case net/http should always come before fasthttp

from gorouter.

Give me some time, need to think about a proper solution for it. For now we could increase test coverage, and maybe remove duplication for logic between routers ?
Right now we have every case done twice for each router.

from gorouter.

Not to worry better have issues open for extended periods rather than rushing to close them before all implications are fully investigated.

What do you mean by

remove duplication for logic between routers

Between the net/http and fasthttp ?

I thought the idea to maintain both was for compatibility reasons since gorouter is a wrapper around them.

from gorouter.

I mean we have same test logic repeated for each implementation of a router, what we should have is one function where you inject router or something like that

from gorouter.

Do we really want to maintain net/http implementation at all since it's way slower for most operations ?

from gorouter.

@mar1n3r0 have a look here 532090c

I split Node interface into two interfaces RouteAware and MiddlewareAware. Still having one Tree and Node types. Router now has two trees one for routes and one for middleware. Route one is sorted by WithRoute method where middleware is not (this solves our issue). Later on when matching path to tree I match separately path against each tree. Most of the tests are failing now because interface has been changed. Most likely there are going to be some bugs but to find them we need to update tests.

Please give it a deep thoughts, if you can see any potential problems now or in the feature with that solution/implementation.

from gorouter.

Amended the tests a tad just to demonstrate that the problem remains: 1cc5ab9

Later on when matching path to tree I match separately path against each tree.

The thing is it's the same tree which is already ordered with static node priority. I think this is a step in the right direction and proves that this can not be solved without a second tree with custom ordering based on middleware index.

It is easier for me to visualize it with layers as an onion like structure. RouteAware nodes are only meant as a gateway and serve no other purpose. So this original RouteTree is used only to validate that the middleware is actually compliant with the registered routes and can start generating its own MiddlewareTree ordered by its own index.

We can take some of the notes from httprouter for the research as gorouter seems to share the same structure: only explicit matches

The limitations of using a single tree with wildcards:

Only explicit matches: With other routers, like http.ServeMux, a requested URL path could match multiple patterns. Therefore they have some awkward pattern priority rules, like longest match or first registered, first matched. By design of this router, a request can only match exactly one or no route. As a result, there are also no unintended matches, which makes it great for SEO and improves the user experience.

named-parameters

Note: Since this router has only explicit matches, you can not register static routes and parameters for the same path segment. For example you can not register the patterns /user/new and /user/:user for the same request method at the same time. The routing of different request methods is independent from each other.

from gorouter.