Does it handle route variables? no

Does it have a middleware stack? no

Martini is a request router not a http server.

You can easily handle route variables yourself with very simple logic.

You can wrap http.HandleFunc to make it behave like middleware.

You do not need to import a framework for these things:

https://vimeo.com/115940590

> You can easily handle route variables yourself with very simple logic.

But you linked a talk that recommends a library to deal with route variables.

> You can wrap http.HandleFunc to make it behave like middleware.

But you linked a talk that recommends a library to deal with middlewares.

Maybe you should review the links you post at first place.

Yes I can write an unmaintainable spaghetti mess, or I can isolate a specific business domain and write or use a library that solves this problem once and for all.

Because at the end of the day it's me who end up testing and running that code, not you.

I think you ought to reconsider what the other guy said. His suggestions were quite good because they lead to simple, idiomatic code that relies solely on the standard library.

You can read more here - https://medium.com/@matryer/the-http-handlerfunc-wrapper-tec...

I read matt ryer's excellent book "Go Blueprints" already. I know all that stuff. I use middlewares with complex logic, I write apps with hundreds of controllers, so with all due respect I'm not going to reinvent the wheel , each time I need to finish a project with tight deadlines.

I don't understand this Go community mindset which says that "nothing is needed but the std lib". My use case isn't Google's or anybody else's.

If the Go team wanted an idiomatic router or middleware stack well they should have provided fully featured ones in the standard lib. There are none. It means "user land".

Have you seen Negroni? It provides a simple framework which solves some the middleware problem. It doesn't use dep injection, the code is more idiomatic and you can use it with any HTTP mux/router you want.

Martini is cool but you probably don't need it.

The main thing lacking from net/http is a flexible router. Using the standard mux and parse params out of the request is doable but something like httprouter is often worthwhile.

Wrapping Handle or HandleFunc is easy enough that you don't really need some framework for middleware. If you keep to the standard interface there is plenty of middleware about if you need it. Though you can use things like Gorilla context for request context it is so easy to use a map of requests pointers to data protected by a mutex it seems silly to use a library to do it.

I feel like Go is a bit of an anti-framework language in general. Anyone trying to offer an all-things-to-everyone solution is going to stray into reflection and interface{} everywhere and I think the more Go you write, the less happy you get with this sort of approach.

Simplified DSL / Routing