4 ms·

I used to be of the same opinion but after writing a lot of Go web services I don’t agree anymore. Go’s HTTP interface is a bit weird and while I am sure there

I used to be of the same opinion but after writing a lot of Go web services I don’t agree anymore. Go’s HTTP interface is a bit weird and while I am sure there is a reason for all the strange choices, for average non-performance critical code I just want interfaces that are easy to use. For example: only being able to ready to body once, not being able to get the status code that was set, … Deviating from the standard allows you to tackle these ‘problems’. In the end I think there is room for multiple frameworks/libs for different styles and purposes.

grose 4y ago
I think this is a perfectly reasonable opinion. Nothing wrong with adding abstractions if you find them useful. I just prefer to combine small stdlib-friendly libraries so I stick with that. Echo (and Gin) are a more 'batteries-included' approach, and their popularity speaks to a demand for that approach.
SPBS 4y ago
It's not difficult to make a stdlib-compatible handler with bells and whistles: just stuff everything into a context and provide helper functions for retrieving those variables from the context. This is what https://pkg.go.dev/github.com/go-chi/chi#URLParam https://pkg.go.dev/github.com/go-chi/chi#URLParam does. Echo and Gin deviate from http.Handler because they want to be frameworks and stamp their framework-specific type signatures all over your codebase.
- leetrout 4y ago
  > just stuff everything into a context and provide helper functions for retrieving those variables from the context That doesn't feel in spirit with the use of context. I am not saying you are wrong just that it makes me realize I would not have even considered doing something like this. Have you worked with a library that does this? Curious if this is this more common than I realize?
  - SPBS 4y ago
    Yeah, the idiomatic (and fast) chi router does this (https://github.com/go-chi/chi#url-parameters https://github.com/go-chi/chi#url-parameters, https://github.com/go-chi/chi/blob/v1.5.4/context.go#L10 https://github.com/go-chi/chi/blob/v1.5.4/context.go#L10). Routing information in stored within a chi Context (https://github.com/go-chi/chi/blob/c9e87efe9691a63d6a89de8bbd16b04fe4d6640e/context.go#L45 https://github.com/go-chi/chi/blob/c9e87efe9691a63d6a89de8bb...) within the request context, simply because there isn't any other way of transmitting data across http handlers. Echo and Gin have their own Context structs, except instead of http.Request wrapping their Context struct, their Context struct wraps http.Request (thereby rendering it incompatible with the stdlib). It's not a far stretch to have these frameworks retrieve their Context from the http.Request. Instead of // echo Handler func(c *echo.Context) { } they could do // standard Go handler func(w http.ResponseWriter, r *http.Request) { c := echo.GetContext(r) }

grose 4y ago

I think this is a perfectly reasonable opinion. Nothing wrong with adding abstractions if you find them useful. I just prefer to combine small stdlib-friendly libraries so I stick with that. Echo (and Gin) are a more 'batteries-included' approach, and their popularity speaks to a demand for that approach.

SPBS 4y ago

It's not difficult to make a stdlib-compatible handler with bells and whistles: just stuff everything into a context and provide helper functions for retrieving those variables from the context. This is what https://pkg.go.dev/github.com/go-chi/chi#URLParam https://pkg.go.dev/github.com/go-chi/chi#URLParam does. Echo and Gin deviate from http.Handler because they want to be frameworks and stamp their framework-specific type signatures all over your codebase.

leetrout 4y ago
> just stuff everything into a context and provide helper functions for retrieving those variables from the context That doesn't feel in spirit with the use of context. I am not saying you are wrong just that it makes me realize I would not have even considered doing something like this. Have you worked with a library that does this? Curious if this is this more common than I realize?
- SPBS 4y ago
  Yeah, the idiomatic (and fast) chi router does this (https://github.com/go-chi/chi#url-parameters https://github.com/go-chi/chi#url-parameters, https://github.com/go-chi/chi/blob/v1.5.4/context.go#L10 https://github.com/go-chi/chi/blob/v1.5.4/context.go#L10). Routing information in stored within a chi Context (https://github.com/go-chi/chi/blob/c9e87efe9691a63d6a89de8bbd16b04fe4d6640e/context.go#L45 https://github.com/go-chi/chi/blob/c9e87efe9691a63d6a89de8bb...) within the request context, simply because there isn't any other way of transmitting data across http handlers. Echo and Gin have their own Context structs, except instead of http.Request wrapping their Context struct, their Context struct wraps http.Request (thereby rendering it incompatible with the stdlib). It's not a far stretch to have these frameworks retrieve their Context from the http.Request. Instead of // echo Handler func(c *echo.Context) { } they could do // standard Go handler func(w http.ResponseWriter, r *http.Request) { c := echo.GetContext(r) }