v2.0.0-beta.4

Last patch. Oversight resulted in being unable to store routers/routes as a value, which is sometimes desired behavior. Packages route and router have been moved out of internal.

v2.0.0-beta.3

Beta 3

Fixes and LOTS of code teardown. Runs a whole 20 nanoseconds faster.

v2.0.0-beta.2

This is the same as the published beta.1. I made a mistake with the module numbering--originally alpha.1 was beta.1, and this has confused the package manager. This should be the most up-to-date code.

Version v2.0.0-beta.1 is erroneous and will be retracted next release.

v2.0.0-alpha.1

2.0.0 alpha release. Focused on cleaning up old code that had no business being around anymore and focusing the public API. May also have made it impossible to use some old features, hence the alpha--need to do some testing with this version before even sort of approaching the release tag.

TODO (11/26/23):

• Testing/documentation is now very out of date
• CORS is lacking an intuitive implementation
• Make sure everything you could do before is still doable

v1.2.2

Matcha v1.2.2

Changes

• Partial routes no longer consider non-alphanumeric paths invalid (no issue)
• Giving Matcha a nil handler now results in a 501 Not Implemented response instead of a panic when trying to call nil handlers (#100)

Developer Notes

This patch squashes some bugs found during internal work with Matcha. The first flew under the radar since running into it required usage of a set of previously-niche functionality, brought into play more by the introduction of Router.Mount. We'd like to introduce some tools for request validation beyond per-part regex validation, but it wasn't right to leave it as an invisible check behind all partials.

The nil handler problem is a bit of a half-fix, and that's by design. Matcha removes control from the user outside of middleware and request handlers; ideally, this control is given back for common cases outside of those, like we do with handlers for 404 when no routes are matched. However, this functionality is provided so that production applications can readily access tools that they should be using. Production APIs should not have nil handlers. If you need more specific behavior, implement that in a handler and register it instead of nil.

What's Next

A break, and then a round of features! Looking at more middleware options and validation for requests as candidates.

v1.2.1

Matcha Version 1.2.1

Hello again! This is a small update. We've made the decision to update our business name from CloudRETIC to Decent Platforms, meaning that links to the GitHub repo for Matcha should be updated. This wouldn't normally be version-worthy, however, Go is pretty tied to GitHub links for versioning. Just to be sure, we're releasing a new version with all-updated links. Happy routing!

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!

v1.1.3

Matcha v1.1.3

Fixes a major bug affecting registration order of routes ending in wildcards.

v1.1.2

Matcha v1.1.2

This update fixes a bug in handling of empty paths, handling them the same as with a path that only contains one slash / so that root paths handle requests to the domain properly.

v1.1.1

Matcha v1.1.1

This release brings a couple of minor internal fixes and one major performance optimization.

Release Details

• middleware.ExecuteMiddleware now executes a full list of supplied middleware; this was previously unexported in package router.
• Documentation, both in and out of code, has been improved. Our repo now includes a user guide, linked to in the README, to walk new users through features.
• Context is now managed by a sync.Pool. This yields a significant performance boost on routers that run continuously (memory use reduced by about 40% in benchmarks).