vardius / gorouter Goto Github PK

Tests could use some refactor, there are multiple case scenario that repeats just for different settings etc.

Hi @vardius

Can you help me understand advantages of gorouter over httprouter ?

Consider following routes:

1. /:name/x
2. /:name/y

And requests:

1. /test/x
2. /test/y
3. /test/z

Should do:

• request 1. should match route 1
• request 2. should match route 2
• request 3. should match no route

What happens:

• request 1. matches route 1
• request 2. matches no route
• request 3. matches no route

TODO:

• add test for following case
• confirm if problem exist
• fix it if exist

Typo: framwework

    router := gorouter.New()
    router.GET("/hello/{name}", http.HandlerFunc(Hello))

    router.USE("GET", "/hello/Joe", someMiddleware)

    log.Fatal(http.ListenAndServe(":8080", router))

Given the example above middleware for path /hello/Joe will be applied to wildcard route /hello/{name} as the path of middleware matches node's path, resulting in middleware being invoked for all requests matching node's pattern.

• /hello/Joe
• /hello/Jerry

etc.

I am trying out the examples and spotted a few typos which prevent some of them running as described. Please share Wiki access so I can fix them as I run the tests.

I am new to Go and would appreciate some help on the following:

import (
        "github.com/vardius/gorouter/v4/context"
)

main.go:10:9: cannot find package "github.com/vardius/gorouter/v4/context"

How does this thing work with version name-spacing ?

• change Params type from map to slice go-slice-search-vs-map-lookup

Following the topic here: #22 (review)

We can take a more general stance and discuss middleware execution order in general.
What we know so far is that the core logic behind generating the tree has a default pattern which it strives to maintain throughout it's whole life cycle:

Sort Nodes in order [statics, regexps, wildcards]

If we abstract away the phases of the gorouter we can conceptualize the following:

• tree generation of nodes with routes - based on router.GET calls
• applying middleware and creating orphaned nodes without routes when there is no match with the existing tree nodes - based on router.USE calls
• processing request path two more phases:
• first checking if the path matches nodes with routes to allow access to middleware layer at all
• applying middleware

The concept is quite clear and neat until the last phase of applying middleware. All phases are going through the same Match loops reusing the same structure and order with some custom processing for orphaned nodes.

Where things get unclear is in the phase of applying middleware. Because it goes through the default ordered structure rather than respecting the user defined middleware order
it contradicts with one of the basic core features of a router namely user defined middleware order of execution:

Mux supports the addition of middlewares to a Router, which are executed in the order they are added if a match is found, including its subrouters.

Although initially discussed in the light of the isolated case concerning orphaned nodes only this seems to be of critical importance to the overall predictability of middleware execution order as the default ordering mechanism will always aim to process statics before regexps before wildcards even if the user defined order is different and more importantly unique each time(not a repeating pattern).

Add more test case, rise coverage to 100%

When pulling through github.com/vardius/gorouter as a dependency, my go.mod file has the +incompatible tag:

module example.com

go 1.12

require github.com/vardius/gorouter v3.0.7-0.20190205101248-eab65e0a6301+incompatible

I think this is because the gorouter repository isn't following the module path conventions for v2+ repositories.

Tested in all middleware scenarios.

func Hello(w http.ResponseWriter, r *http.Request) {
	params, _ := context.Parameters(r.Context())
	fmt.Fprintf(w, "params: %v\n", params)
	fmt.Fprintf(w, "hello, %s!\n", params.Value("name"))
}

URL mock:

http://localhost:8080/hello/test

output:

params: []
hello, !

Context package imported as suggested with:

export GO111MODULE=on
go get -u -v github.com/vardius/gorouter/v4/context