6 ms·

I'm not a big fan of Echo using nonstandard context types and nonstandard function signatures for its handlers/middleware. It boxes you into making "Echo librar

by grose 4y ago

I'm not a big fan of Echo using nonstandard context types and nonstandard function signatures for its handlers/middleware. It boxes you into making "Echo libraries" instead of "HTTP libraries". I would recommend chi for those who want something that plays nicely with the standard library: https://github.com/go-chi/chi https://github.com/go-chi/chi

hit8run 4y ago
Wanted to say the same! Standard handler signature is quite helpful.
abdusco 4y ago
I like that it provides a useful set of methods over raw stdlib types. If you need to integrate other libs, it's quite easy to wrap them and call ServeHTTP(w, r)
Cwizard 4y ago
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) }
JodieBenitez 4y ago
Isn't it the same as *gin.context in go gin ? From what I see (not an experienced Go programmer), in gin you get the request through gin.context and in Chi you get the context through the request ?
- grose 4y ago
  The context package didn't exist when Gin was created, so they invented their own solution. There was a proliferation of these context types until the standard library created a common solution. chi uses it, but Echo doesn't. The biggest advantage is that the stdlib context key type is interface{}, so you can use unexported types to create private key namespaces. It's also immutable and thread-safe. Gin and Echo use plain strings that are easy to clobber. This blog post discusses how the stdlib context works: https://go.dev/blog/context https://go.dev/blog/context (see userip bit about the unexported types). In many ways, Echo is a "better Gin".
  - JodieBenitez 4y ago
    Thanks for taking the time to explain. I see Gin can expose the stdlib context: router.GET("/", func(context *gin.Context) {context.Request.Context()}) > In many ways, Echo is a "better Gin". Interesting. I find it difficult to compare the plethora of web frameworks in Go. But coming from Python, I'm also familiar to this kind of situation...
konart 4y ago
Same here. I can see how having Echo's build-ins be a benefit if you have a pretty big applications with rich API and quite a few people working on it. But in case for microservices - it's just makes things needlessly complicated.

by grose 4y ago

hit8run 4y ago

Wanted to say the same! Standard handler signature is quite helpful.

abdusco 4y ago

I like that it provides a useful set of methods over raw stdlib types. If you need to integrate other libs, it's quite easy to wrap them and call ServeHTTP(w, r)

Cwizard 4y ago

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) }

JodieBenitez 4y ago

Isn't it the same as *gin.context in go gin ? From what I see (not an experienced Go programmer), in gin you get the request through gin.context and in Chi you get the context through the request ?

grose 4y ago
The context package didn't exist when Gin was created, so they invented their own solution. There was a proliferation of these context types until the standard library created a common solution. chi uses it, but Echo doesn't. The biggest advantage is that the stdlib context key type is interface{}, so you can use unexported types to create private key namespaces. It's also immutable and thread-safe. Gin and Echo use plain strings that are easy to clobber. This blog post discusses how the stdlib context works: https://go.dev/blog/context https://go.dev/blog/context (see userip bit about the unexported types). In many ways, Echo is a "better Gin".
- JodieBenitez 4y ago
  Thanks for taking the time to explain. I see Gin can expose the stdlib context: router.GET("/", func(context *gin.Context) {context.Request.Context()}) > In many ways, Echo is a "better Gin". Interesting. I find it difficult to compare the plethora of web frameworks in Go. But coming from Python, I'm also familiar to this kind of situation...

konart 4y ago

Same here. I can see how having Echo's build-ins be a benefit if you have a pretty big applications with rich API and quite a few people working on it. But in case for microservices - it's just makes things needlessly complicated.