-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mux/v2: need feedback #130
Comments
Other thoughts:
Also worth reading (in case you haven't yet) is the plan to move Keen to see where this is going. |
Edit: I moved the API draft to a gist to update it as proposals arrive. Here it is: https://gist.github.com/moraes/fba14ffd6c3e091b2c68
|
Declaration syntax draft. Nothing is set in stone, etc. // creates a new router
r := New()
// -------------------------------------------
// basic usage: host, path and method matching
// -------------------------------------------
// matches a static path
r.Handle("/foo/bar", myHandler)
// matches a path with a variable
r.Handle("/foo/{bar}", myHandler)
// matches a path prefix
r.Handle("/foo/{*}", myHandler)
// matches a path with a variable and the given HTTP verb.
r.Handle("/foo/{bar}", myHandler).Methods("GET")
// matches a host and path
r.Handle("www.mydomain.com/foo/bar", myHandler)
// ------------------------------
// extended usage: path subrouter
// ------------------------------
s := r.Sub("/users")
s.Handle("/new", myHandler) // matches "/users/new"
s2 := s.Sub("/{id}")
s2.Handle("/", myHandler) // matches "/users/{id}/"
s2.Handle("/tickets", myHandler) // matches "/users/{id}/tickets"
// ------------------------------
// extended usage: host subrouter
// ------------------------------
s := r.Sub("{subdomain}.mydomain.com")
s.Handle("/foo/{bar}", myHandler) // matches "{subdomain}.mydomain.com/foo/{bar}" |
I think we should wait till the net/context situation is resolved before making the API. It could totally change the design and drop the need to use gorilla/context at all. The other option is to build it with the current x/net/context for now and then migrate to the standard library version. |
Setting/retrieving variables can be left as "undefined" or "subject to changes" until a context resolution comes, and we take our time to discuss features, declaration syntax and the broader general API. That said, I'll talk a bit about... Declaration syntaxThe general idea is that we don't need to have r := mux.New()
r.Handle("/foo", myHandler) // matches "/foo" in any scheme and host
r.Handle("/bar/{*}", myHandler) // matches the path prefix "/bar/" in any scheme and host
s1 := r.Sub("//{subdomain}.mydomain.com")
s1.Handle("/{baz}", myHandler) // matches "//{subdomain}.mydomain.com/{baz}" in any scheme
s2 := r.Sub("https://{subdomain}.mydomain.com")
s2.Handle("/{baz}", myHandler) // matches "https://{subdomain}.mydomain.com/{baz}" Notes:
That's all for now. Let me know what you hate most, other ideas etc. ✌️ |
I like the model where dispatching is logically by path and then method:
Examples:
If there's no match on method for a given route, than the mux replies with status 405. |
To handle URI path segments containing an encoded "/", the router should dispatch on req.RequestURI instead of req.URL.Path. Matched variables are percent decoded. For example:
matches "/foo/hello%2fworld/baz" with the variable bar set to "hello/world". |
More specific patterns should override less specific patterns. In this example,
the path "/help" should dispatch to serveHelp. Left to right order should be used as a tiebreaker. In this example
the path "/help/folllowers" should dispatch to serveHelpTopic with variable "topic" set to followers. |
The router should automatically handle redirects for "/" at end of the path.
|
@margaery: I took a quick look at RFC 6570, and that's a huge spec. We are doing simple string expansion with
|
Gary's requests are all great - automatic slashes are very useful. One additional thing on my list: support for automatic OPTIONS responses, |
Some more suggestions:
|
|
@elithrar: A default OPTIONS handler would be trivial to define, as well as a 405 handler that sets a proper Allow header (somewhat related). This remained unsolvable in current gorilla/mux because the same URL pattern can lead to different Routes, and it is not easy to identify "same URL pattern" because of regexps and separated matchers for host, scheme etc. In the new design each URL pattern always leads to the same Route, which knows about the methods it supports. @garyburd, @elithrar: RE middleware in subrouters: I think we are again on the right direction here, because subrouters are just dumb factories that create routes with a given pattern prefix (they are not "nested"; they just carry a prefix). A subrouter could also carry a middleware list to pass to routes (or to sub-subrouters, which could have extra middleware). The exact API is something to discuss ( Re: functional options: I need to think about it. The example was not very obvious to me, but I'm tired or something is missing. I moved the API draft to a gist to update it as proposals arrive. Here it is: |
@moraes How about creating a repo for the new mux and writing the proposal as godoc? People can propose changes or request features using issues and PRs in that repo. |
New repo or new branch? I want to push my prototype in the following days. |
I suggested a new repo because I assumed that the new mux will be published in a new repo. Where do you plan publish the new mux? |
New repo on a non-master branch (and push a one-liner README to the On Mon, Oct 26, 2015 at 9:28 AM Gary Burd notifications@github.com wrote:
|
New repo is ok. :) The spice must flow. |
This discussion has now its own place: gorilla/muxy. It may be a temporary repo or not. We will see.
Thanks for the great feedback so far. 👍 |
+1 to the idea of returning HTTP 405's in the appropriate places (eg. if a request is made to a URI that has a .Methods() filter on it that doesn't allow it) |
The new (in progress) https://github.com/gorilla/muxy library should be On Thu, Jan 7, 2016 at 12:42 PM Nathan Sullivan notifications@github.com
|
I'd like to start a conversation and brainstorm about the future of gorilla/mux.
Background: gorilla/mux has evolved to be the most featureful router in Go, but this came with a price: the API feels bloated and has unneeded complications. It is also far from shining in benchmarks compared to other routers (not that gorilla/mux is a bottleneck to care about, but not-so-shiny numbers give a bad impression to new users).
I'd like to take gorilla/mux to the next level with these goals in mind:
After playing around, I came up with an implementation draft that is a radical departure from what gorilla/mux is now, and to achieve the slim-intuitive-fast goals some cuts were made:
...but the most controversial ones are probably:
The initial result is a much slimmer mux which, besides the elemental features (scheme, host, path and method matching), offers some conveniences not easily found in other packages (subrouting, URL building), and a damn high speed (teaser: it almost beats net/http in static matching and knocks out everybody else in matching with variables; and, oh, it doesn't make a single memory allocation for any match — zero, zip, zilch, nada).
But this is not gorilla/mux. It is something else. Maybe it doesn't even exist! Well, maybe it does. Enough teasing for now: I'd like to hear your crazy ideas, frustrations and aspirations for gorilla/mux, and to ask how could we manage an eventual API breakage in the best possible way.
The text was updated successfully, but these errors were encountered: