What does HackerNews think of httprouter?

I wonder if the new version takes the opportunity to make the muxer faster. I needed a path matcher / muxer and I settled on forking julienschmidt/httprouter [1] into my own project, pathmatcher [2]. What I like about the original it is that it uses a trie for mapping paths to handlers, which can look up routes very quickly [3], and is optimized for low/zero allocations. My changes generalizes it (the 'handler' value can be any generic type) and exposes the underlying data structure so you can do non-http.Handler things with it if you want.

[1]: https://github.com/julienschmidt/httprouter

[2]: https://github.com/infogulch/pathmatcher

[3]: https://github.com/julienschmidt/go-http-routing-benchmark

At a previous job we did a 'tech experiment' to write a Go REST service. As far as I'm aware it's still in use in a production-level capacity. It used the following:

- gotest

- No DI, but in hindsight this would have been the right thing to do. The dev team is 100% Python, so mocking was more the talk of the office than DI/IoC.

- For routing and HTTP the service used httprouter https://github.com/julienschmidt/httprouter

I think it's a fantastic language, gofmt and gotest are both great utilities, and the short time to create an executable made development turnaround a breeze.

However, I think for the purposes of a simple REST service I would probably use Python/Flask. Less boilerplate and for a Python team, it would have made more sense ...

- Web: No framework, I mostly use https://goswagger.io but for basic stuff then just the standard http library + https://github.com/julienschmidt/httprouter

- Testing: https://golang.org/pkg/testing/ + https://pkg.go.dev/mod/github.com/stretchr/testify

- Mocks: https://github.com/golang/mock

- Dependency Injection: None, current user of https://github.com/uber-go/dig and I regret it.

After building apps in Martini and Revel, I’ve moved to using a smattering of decent (IMHO) packages good at 1 thing:

Let me render templates in a layout file with `yield` - https://github.com/unrolled/render

Let me quickly route with param support - https://github.com/julienschmidt/httprouter

Sessions, flash messages, and secure cookies - http://www.gorillatoolkit.org/pkg/sessions

POST parameter-to-structure binding (this is optional and easy enough to do by hand) - https://github.com/mholt/binding

I write my own middlewares for logging, auth, etc. Use viper for configuration, gorm for an ORM, and for anything more complicated, accept that you’re about to learn a whole lot about it because you’re gonna be writing it yourself.

gin[1] is a popular off-the-shelf solution that provides a lot of functionality for you. But as everdev said, it's pretty normal to gradually build up your own stack using the stdlib and possibly some smaller, more focused packages like httprouter[2] and the gorilla toolkit[3].

I actually have learned a lot about HTTP/HTTPS servers by working on a lower level and building up my stack! I recommend just starting with the stdlib and importing 3rd party code where you feel yourself limited by it. The first thing people probably adopt is a more expressive router.

[1] https://github.com/gin-gonic/gin

[2] https://github.com/julienschmidt/httprouter

[3] https://github.com/gorilla

Using no frameworks at all, only https://github.com/julienschmidt/httprouter for routing.

Features

- Effective and flexible middlewares flow control, create anything by middleware

- Powerful and smart error handler, make development easy

- Trie base gear.Router, it is as faster as [HttpRouter](https://github.com/julienschmidt/httprouter), but more powerful

- Integrated timeout context.Context

- Integrated response content compress

- Integrated structured logging middleware

- Integrated request body parser

- Integrated signed cookies

- Integrated JSON, JSONP, XML and HTML renderer

- Integrated CORS, Secure, Favicon and Static middlewares

- More useful methods on gear.Context to manipulate HTTP Request/Response

- Completely HTTP/2.0 supported

Gorilla mux is way overrated and overused. I'm not sure why it's the first choice for so many people. There are much better alternatives such as https://github.com/julienschmidt/httprouter or https://github.com/gin-gonic/gin.

Parts of the readme are copied from [0] julienschmidt/httprouter...

"In contrast to the default mux of Go's net/http package, this router supports variables in the routing pattern and matches against the request method. It also scales better."

[0] https://github.com/julienschmidt/httprouter

Does it use a trie? If not, it probably should. Here's a wonderful talk on using that datastructure (with go) for the gov uk url router:

https://gdstechnology.blog.gov.uk/2013/12/05/building-a-new-...

The Vulcan proxy from Mailgun does the same thing:

http://vulcand.github.io/proxy.html#route

It looks like it doesn't, so existing open source golang url routers will perform much better, contrary to this post. The one in vuland is interesting in that it supports both regex AND tries, so you get the best of both.

Additionally, httprouter (golang) uses a trie and is fast as hell:

https://github.com/julienschmidt/httprouter

Edit: Adding another one (thanks buro9!) that is used in production by CloudFlare:

https://github.com/pressly/chi

Interesting approach. I guess there are use cases where the small number of allocs of some of the other routers is enough to cause problems.

I'll definitely stick to httprouter as my default starting point, though. The params interface is much nicer, and it's pretty damn good with performance and allocation count: https://github.com/julienschmidt/httprouter

For the routing side of things, HttpRouter[0] seems like a nice alternative when performance matters to you. But as the author of this post referred to, sticking with the basics is a nice way to go. The nice thing about a lot of these frameworks, is that you can use bits and pieces of them if you'd like, you aren't required to use all the functionality.

[0] https://github.com/julienschmidt/httprouter

About this part in README:

> I have very little interest in boosting Goji's router's benchmark scores. There is an obvious solution here--radix trees--and maybe if I get bored I'll implement one for Goji, but I think the API guarantees and conceptual simplicity Goji provides are more important (all routes are attempted, one after another, until a matching route is found). Even if I choose to optimize Goji's router, Goji's routing semantics will not change.

Maybe you can just use HttpRouter without reimplementing it yourself?

https://github.com/julienschmidt/httprouter

> The router is optimized for best performance and a small memory footprint. It scales well even with very long pathes and a large number of routes. A compressing dynamic trie (radix tree) structure is used for efficient matching.

    goji.Get("/hello/:name", hello)

    router := httprouter.New()
    router.GET("/hello/:name", Hello)