v1.2.0

Matcha v1.2.0

Matcha's second minor update is here!

Changes

• Add compatibility with the traditional middleware signature func(next http.Handler) http.Handler
• Implement functionality for Patterns; strings that contain regex in {}
• Create package route/require. Route requirements serve as non-route parameters to match against requests, but cannot modify context or reject requests outright.
• Updated handling signatures from AddRoute to Handle, HandleFunc, HandleRoute, and HandleRouteFunc
• New user guide walking through the key features of Matcha in documentation
• Updated benchmarks
• Mount subrouters for composable APIs
• New native middleware for query parameters and headers using Patterns

FAQ

What's the difference between Middleware and Requirements? Why implement them separately?

The difference is the result of rejecting a request. When Middleware rejects by returning nil, the request is dropped, the router assumes that the middleware wrote out a valid response, and the goroutine is cleaned up as normal. When Requirements reject a request by returning false, the router continues trying to match against subsequent registered routes.

This means that requirements allow you to specialize behavior based on request properties, rather than reject them outright. Currently, Matcha has native support for this behavior on the hostname the request was sent to, so if you have a router servicing multiple subdomains, domains, or ports, you can specialize behavior between them. Think api.google.com vs www.google.com.

The engineering reason for separating the definitions is that Requirements are checked at a place in routing when context must not be modified, so using the Middleware definition (which is explicitly able to modify context) couldn't work.

Why was the comparative benchmark dropped from the README?

I wrote a long-form post about this on my blog here, but in short: it wasn't helpful. Developers should have a strong understanding of their performance and capability needs and the ability to test different tools to see what works best for them. Matcha now provides this with examples, documentation, high test coverage, support, and an end-to-end benchmark that accurately represents performance in a fully-featured router.

Matcha isn't the fastest router--it's majorly outpaced by Gin and just a touch slower than Chi--but I'm confident enough in its feature-to-performance ratio to let it stand on its own, without the front-and-center comparison to other projects.

What's Next

I will be focusing on minor, community-requested features (middleware/requirements, convenience things) and bugfixes for the time being. Matcha is in a stable and capable place, and I have a couple of big projects I'm really excited to work on and share with you all!