Hacker News Reader

Comment by grose | Hacker News Reader

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

View on HN

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.

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.

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 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.

> 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?

Yeah, the idiomatic (and fast) chi router does this (https://github.com/go-chi/chi#url-parameters, 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/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)
    }

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)

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 ?

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 (see userip bit about the unexported types).

In many ways, Echo is a "better Gin".

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...

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

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.

Reply on news.ycombinator.com