Thanks for opening your first issue here! 🎉 Be sure to follow the issue template! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord

thx for the report
there is indeed a problem

https://expressjs.com/de/api.html#router.methods

but the current logic packs the handler after the middlewares

@pjebs was there a reason for this ?
it is coming from #2176

my fix would be

@ReneWerner87 Maybe it can be fixed this way?

handlers := middleware
handlers = append(handlers, handler)

no, that's how it was before and nothing will change
if we say that the last parameter with the other handlers is the stack and we add the handler to the stack, it ends up at the end

@ReneWerner87 May I ask what is the difference between handlers = append(handlers, handler) and handlers = append([]Handler{handler,handlers...}) What's the difference?

The order of the registered handlers under the route and with this the order of the process.

I actually haven't been involved in v3 at all.
I did propose a change to a laravel style ordering a few years back but it created lots of pushback due to departure from express.

I remember someone did a survey at one point and my suggestion was popular, but last I remember there was going to be a configuration to pick your preferred ordering.

It looked like my suggestion got merged, in which case your ordering is wrong. The docs will need to get updated since it was merged.

The compulsory end handler comes first (because every endpoint by definition needs a handler), then the list of (optional) middlewear. In practice, you would have a whole group of routes that require authMiddleware so adding ad-hoc middleware is not the usual way in a real-world application.

See #2160.

v2 definition:

type Router interface {
	Use(args ...interface{}) Router

	Get(path string, handlers ...Handler) Router
	Head(path string, handlers ...Handler) Router
	Post(path string, handlers ...Handler) Router
	Put(path string, handlers ...Handler) Router
	Delete(path string, handlers ...Handler) Router
	Connect(path string, handlers ...Handler) Router
	Options(path string, handlers ...Handler) Router
	Trace(path string, handlers ...Handler) Router
	Patch(path string, handlers ...Handler) Router

	Add(method, path string, handlers ...Handler) Router
	Static(prefix, root string, config ...Static) Router
	All(path string, handlers ...Handler) Router

	Group(prefix string, handlers ...Handler) Router

	Route(prefix string, fn func(router Router), name ...string) Router

	Mount(prefix string, fiber *App) Router

	Name(name string) Router
}

v3 definition:

It would be good if the signature could be changed for these:

	Get(path string, handler Handler, middleware ...Handler) Router
	Head(path string, handler Handler, middleware ...Handler) Router
	Post(path string, handler Handler, middleware ...Handler) Router
	Put(path string, handler Handler, middleware ...Handler) Router
	Delete(path string, handler Handler, middleware ...Handler) Router
	Connect(path string, handler Handler, middleware ...Handler) Router
	Options(path string, handler Handler, middleware ...Handler) Router
	Trace(path string, handler Handler, middleware ...Handler) Router
	Patch(path string, handler Handler, middleware ...Handler) Router

	Add(method, path string, handler Handler, middleware ...Handler) Router
	All(path string, handler Handler, middleware ...Handler) Router

Secondly,

// Note: methods plural
Add(methods []string, path string, handler Handler, middleware ...Handler) Router

@vrnvu

The end-handler goes first and the list of optional middleware goes at the end so your code should be:

	app.Get("/", func(c fiber.Ctx) error {
		return c.SendString("Welcome")
	})

	app.Get("/allowed", func(c fiber.Ctx) error {
		return c.SendString("Successfully authenticated!")
	}, authMiddleware, middleware2, middleware3)

If you are adamant on using strict Express style ordering you can also just pass nil for your handler and pretend everything is middleware:

	app.Get("/", func(c fiber.Ctx) error {
		return c.SendString("Welcome")
	})

	app.Get("/allowed", nil, authMiddleware, func(c fiber.Ctx) error {
		return c.SendString("Successfully authenticated!")
	})

That way you can still see "the flow" the request travels through.

However,

In practice, you would have a whole group of routes that require authMiddleware so adding ad-hoc middleware is not the usual way in a real-world application.

In the short-term, you can also define a function to remind yourself (and not get mentally confused) of Express ordering. That way if you forget the new signature, it will create a compile-time error to remind you:

	func Express(handlers ...Handler) []Handler {
		return handlers
	}

	// Legacy pattern
	func X(handlers ...Handler) []Handler {
		return handlers
	}


	app.Get("/allowed", nil, X(authMiddleware, func(c fiber.Ctx) error {
		return c.SendString("Successfully authenticated!")
	})...)

okay thanks for the explanation
as we tend to follow express concepts, i would change the internal sequence
I didn't notice that at the time
additional ideas from other frameworks/languages are fine as long as they don't conflict with the flow/concept of epxressjs

my fix would be

@ReneWerner87 You will need to actually change the signature back to v2 rather than your adjustment (which will work) but it contradicts the signature.

According to the proposal: #2160 (if memory serves me correctly since it was 2-3 years ago)

My understanding after the proposal was that a survey was done by someone on the Fiber team that revealed it was very popular (after some initial backlash) and then you merged it.

Then I remember you made a comment that you wanted it to be configurable to accept both signatures.

Also note, the v3 signature is consistent with Express provided you pass nil for the second argument.

Also note, as per @vrnvu, he/she naturally named his middleware: authMiddleware. The v3 function's signature implies where it belongs.

Lol I guess that's the end of that experiment