alexedwards/flow

A delightfully tiny but powerful HTTP router for Go web applications

flow's Issues

any interest in generating the http.Request for the client side?

Like for example rata.NewRequestGenerator(), see https://github.com/tedsuo/rata
If not, how would you suggest implementing the client side of an API?
thanks!

Curious about your opinion on Go routing proposal

Hi, sorry if this is a bad way to contact you, but I wonder if you have any feedback for the recent ServeMux proposal: golang/go#61410

Proposal: Optimize HTTP Router for Improved Performance and Code Efficiency

Problem:

The current implementation of the HTTP router suffers from redundancy and inefficiencies, particularly in route handling. Routes with the same path but different HTTP methods or handlers lead to duplicated route definitions, increased memory consumption, and slower lookup times.

Example:

package main

import (
	"fmt"
	"net/http"
	"test/pkg/flow"
)

func main() {
	mux := flow.New()
	mux.HandleFunc("/index", indexHandler, "GET", "POST")
	mux.HandleFunc("/index", indexPutHandler, "PUT")
	mux.HandleFunc("/index", indexDeleteHandler, "DELETE")

	fmt.Println(*mux.GetAllRoutes())
}

func indexHandler(w http.ResponseWriter, r *http.Request)       {}
func indexPutHandler(w http.ResponseWriter, r *http.Request)    {}
func indexDeleteHandler(w http.ResponseWriter, r *http.Request) {}

type Mux struct {
	NotFound         http.Handler
	MethodNotAllowed http.Handler
	Options          http.Handler
	routes           *[]route
	middlewares      []func(http.Handler) http.Handler
}

// for testing purposes
func (m *Mux) GetAllRoutes() *[]route {
	return m.routes
}

Output:

[{GET [ index] false 0x100a99160} {POST [ index] false 0x100a99160} {HEAD [ index] false 0x100a99160} {PUT [ index] false 0x100a99170} {DELETE [ index] false 0x100a99180}]

Proposed Solution:

To address these issues, I propose optimizing the HTTP router by consolidating routes with the same path into single route objects and internally mapping HTTP methods to their corresponding handlers. This approach reduces memory usage, streamlines route matching, and simplifies the codebase. By leveraging maps for method-handler associations, we achieve faster lookup times and improved runtime performance.

Implementation Details:

1. Route Consolidation: Routes with the same path will be consolidated into single route objects.
2. Method-Handler Mapping: Internally within each route object, HTTP methods will be mapped to their corresponding handlers using a map data structure.
3. Route Matching Refinement: The route matching logic will be simplified to focus solely on comparing the request's path to the route's path. Once a matching route is found, the appropriate handler based on the request's HTTP method will be retrieved from the route's internal map (405 in case HTTP-Method is not supported).
4. Code Refactoring: The codebase will be refactored to encapsulate method-handler associations within route objects, promoting better code organization and maintainability.

P.S This is my first-ever issue/proposal so feel free to correct and educate me in case I am wrong or missing something!
P.S.S @alexedwards In case this proposal seems reasonable I will be more than happy to create a PR :)

Question: why making a copy rather than passing the derefrenced value directly?

https://github.com/alexedwards/flow/blob/1828f587dbe5c8a465ca74250f696e1d51f89f79/flow.go#L161C1-L164C2

Hello Mr. Edwards,
hope you are doing well!

func (m *Mux) Group(fn func(*Mux)) {
	mm := *m
	fn(&mm)
}

I wonder why making a copy of m and then passing the address of the newly created copy to the function, isn't better to update the function declaration to accept Mux instead of *Mux and passing the dereferenced value of m?

func (m *Mux) Group(fn func(Mux)) {
	fn(*m)
}

Comparison

The functionality will remain the same.
The differences between them are:

• in the current implementation, a copy of m is created, then a copy of the address will be created, and the (*Mux).Group function contains 2 lines of code.
• in the proposed implementation, a copy of m will be created, and the (*Mux).Group contains only 1 line of code.

can't mount handler for fileserver

I have public folder and inside public folder I have test.html

	mux := flow.New()
	fs := http.FileServer(http.Dir("public"))
	mux.Handle("/public/", http.StripPrefix("/public/", fs))
	err := http.ListenAndServe(fmt.Sprintf(":%v", config.Get().ServerPort), mux)

http://localhost:5555/public/test.html does not serve the page

however if I change that with default mux I get my html page. I will try to debug it but I am openning issue just in case you spot the problem quickly

Unexpected % Appended To Param Value.

I'm working through Let's Go Further for the second time. I'm using the Flow router this time. I'm on chapter 2 of the book and I've built out 3 basic routes.

package main

import (
	"net/http"

	"github.com/alexedwards/flow"
)

func (app *application) routes() http.Handler {

	// initialize a new router (flow router from Alex Edwards)
	router := flow.New()

	// Routes --------------------------------------------- //
	router.HandleFunc("/v1/healthcheck", app.healthcheckHandler, "GET")
	router.HandleFunc("/v1/widgets", app.createWidgetHandler, "POST")
	router.HandleFunc("/v1/widgets/:id", app.getWidgetHandler, "GET")

	return router

}

Here's my getWidgetHandler function:

func (app *application) getWidgetHandler(w http.ResponseWriter, r *http.Request) {

	// get the id value as a string.
	stringId := flow.Param(r.Context(), "id")

	fmt.Fprintf(w, "id: %s", stringId)

}

I sent the following curl request:

curl localhost:4000/v1/widgets/123

I would expect to get the following output:

id: 123

However, I'm getting:

id: 123%

Oddly enough, if I use fmt.Println(stringId) the output is 123.

Am I doing something wrong? Or is this a bug?

Thanks,

Chris

Suggestions

Very cool! I like this a lot. I wrote my own router which is also a sort of stripped down take on Chi/Way/httprouter. It's interesting to see more versions of this idea.

Some thoughts:

• .Use(mw) can be changed to .Use(mws...) to save some typing in some cases.
• Integer params come up a lot, so func ParamInt[Int int|int32uint32|int64|uint64](ctx context.Context, param string, n *Int) (ok bool) would be nice to have.
• I find that mounting static files also comes up a lot, so I wrote a Router.Mount convenience method. Something to think about.
• It would be faster at route time but also better in terms of failing fast to parse the regexes up front. I suggest changing routes to

type route struct {
	method   string
	segments []string
	matchers []*regexp.Regexp 
	wildcard bool
	handler  http.Handler
}

and Handle to

	segments := strings.Split(pattern, "/")
	var matchers []*regexp.Regexp
	for _, seg := range segments {
		key, rxpattern, ok := strings.Cut(seg, "|")
		if !ok {
			continue
		}
		rx := regexp.MustCompile(rxpattern)
		matchers = append(matchers, rx)
	}
	for _, method := range methods {
		route := route{
			method:   strings.ToUpper(method),
			segments: segments,
			matchers: matchers,
			wildcard: strings.HasSuffix(pattern, "/..."),
			handler:  m.wrap(handler),
		}
		
		*m.routes = append(*m.routes, route)
	}

And in match you can just use the next matcher in the slice whenever you see a pipe.

Mounting suppot

Very nice router! I like it very much.
Have a question. How can I mount multiple sets of routes like chi.Mount() does. For example I have some subdomens/components, each with their own routes set. How can I wire them together for passing to main http.Server?