vardius / gorouter

Go Server/API micro framework, HTTP request router, multiplexer, mux

🍃 gorouter

Go Server/API micro framework, HTTP request router, multiplexer, mux.

📖 ABOUT

Contributors:

• Rafał Lorenz

Want to contribute ? Feel free to send pull requests!

Have problems, bugs, feature ideas? We are using the github issue tracker to manage them.

📚 Documentation

For documentation (including examples), visit rafallorenz.com/gorouter

For GoDoc reference, visit pkg.go.dev

🚅 Benchmark

➜  gorouter git:(master) ✗ go test -bench=. -cpu=4 -benchmem
test
goos: darwin
goarch: amd64
pkg: github.com/vardius/gorouter/v4
BenchmarkNetHTTP-4              	65005786	        17.9 ns/op	       0 B/op	       0 allocs/op
BenchmarkFastHTTP-4             	69810878	        16.5 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	github.com/vardius/gorouter/v4	3.808s

👉 Click here to see all benchmark results.

Features

• Routing System
• Middleware System
• Authentication
• Fast HTTP
• Serving Files
• Multidomain
• HTTP2 Support
• Low memory usage
• Documentation

🚏 HOW TO USE

• Basic example
• net/http
• valyala/fasthttp

🖥️ API example setup

• Go Server/API boilerplate using best practices DDD CQRS ES.

📜 License

This package is released under the MIT license. See the complete license in the package:

gorouter's Issues

Incompatible tag in go.mod

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.

Refactor tests

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

Wildcard node matching

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

General middleware execution order

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).

Context params missing

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

Fix Wiki small code example typos

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 ?

When to prefer gorouter over httprouter

Hi @vardius

Can you help me understand advantages of gorouter over httprouter ?

Static path middleware is applied to all wildcard paths

    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.

Add more test case

Add more test case, rise coverage to 100%

typo in project description

Typo: framwework

Performance Upgrades

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