5 ms·

Labstack/echo: High performance, minimalist Go web framework

91 points by kiyanwang 4y ago

Karupan 4y ago
I just started using echo for a personal project - just a boring old server rendered webapp. Overall, it has some niceties which can save a lot of time. The documentation and cookbook cover the most common usage patterns. I like that it doesn't enforce too many conventions unlike Rails/Django. P.S: Logging is still a bit of mess in the Go ecosystem!
- Cwizard 4y ago
  Could you elaborate why logging is a mess in the Go ecosystem?
  - fredrikholm 4y ago
    Wouldn't call it a mess, but there is less consensus amongst the community. Logging is one of the areas where there is no established standard. That said, Zap (by Uber) has proved itself and is a solid choice. We've used it in several projects at [company], handling very high loads.
    - gabereiser 4y ago
      Didn't the Go team say that there's a logging interface and that's where they are going to leave it. If you want more robust logging, you can add it. log.New() is for that purpose. If you want a struct-log, you'll have to define one for your needs. Logging is very environment specific. What I log to the console locally is different from what I log to, say, AWS CloudWatch in production. I think the stance on logging by the core Go team is the right way to go about it. Just provide a basic logger, an interface, and let the projects determine how they want to route those logs and what kind of data should it include.
      - qzio 4y ago
        Can you provide a link to this interface? The log package in stdlib doesn’t let you specify levels, just a Printf unless Iam mistaken, and it is not an interface I believe.
        gabereiser 4y ago
        Ah, it's not an interface but a struct. My mistake. The syslog part of the log package allows you to specify the priority. https://pkg.go.dev/log/syslog@go1.19#Priority https://pkg.go.dev/log/syslog@go1.19#Priority
fileeditview 4y ago
I've used Echo on a few occasions and it is nice little Go web framework.. or more a library.. it doesn't bringt much extra fuzz. The reason why I chose Echo among all of the Go web "frameworks" was that it didn't use FastHTTP, which is used by many (most?). I however ran into a (simple) pattern of endpoints a long time ago that you could not be matched by FastHTTP and realized the speed improvements may not be worth it. There was also no http2 support back then. Too many people just look at micro-benchmarks for these frameworks.
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.
molly0 4y ago
For someone (me) that started to get into Go 4 days ago. What is the difference between a framework like this and Gin?
- xvello 4y ago
  Gin and Echo cover similar feature scopes (the HTTP plumbing around your business logic, that you write in handler functions), but I chose Echo for my project[1] because: - it ships a pretty extensive collection of middlewares that will get you to 80% faster - the documentation[2] is really well written and accessible to new web developers: most "must have" features have a cookbook page, so you don't have to google for blog posts. - it does indeed use a custom handler function signature, but in my opinion this one is better (returning errors instead of handling them locally in each handler). You can still use handlers and middlewares written for other frameworks (for example the great statigz[3] handler) through the `echo.WrapHandler` and `echo.WrapMiddleware` functions [1] https://github.com/letsblockit/letsblockit https://github.com/letsblockit/letsblockit [2] https://echo.labstack.com/guide https://echo.labstack.com/guide [3] https://github.com/vearutop/statigz https://github.com/vearutop/statigz
  - molly0 4y ago
    Thank you for this answer, it’s great to get tips like this when starting with a new language.
- fredrikholm 4y ago
  No real difference. They both deviate from standard interfaces (eg. https://pkg.go.dev/net/http#Handler https://pkg.go.dev/net/http#Handler) and do their own thing. This is fine, but unidiomatic. The Go community steers towards 'one way of doing things', meaning that packages that don't reuse established interfaces tend to be less popular compared to the ones that do (gorilla, chi, or just std).
  - molly0 4y ago
    Thanks!
uo21tp5hoyg 4y ago
Their rendering handling seems to be a lot better than gofiber's[1] which downloads nearly 1,000 packages and sadly that ruled it out as a viable framework when I was looking for web frameworks to use. [1] https://github.com/gofiber/template/blob/master/go.sum https://github.com/gofiber/template/blob/master/go.sum
- deleted 4y ago
  [deleted]
- m90 4y ago
  A package appearing in go.sum does not necessarily mean it's being used. It just means it has been downloaded once, but might have been replaced by some other version at some point.
  - salmo 4y ago
    This has bitten me before. A security scanner reported a vulnerability from this that was blocking me from my “use X at work” request. I ended up having to teach the vendor of the tool about go mod. But if you are publishing a “release” I personally think it is good to tidy that up. Even just to prevent misconceptions. No reason to preserve ancient versions and especially failed library experiments.
  - omginternets 4y ago
    Is there a safe way to de-bloat go.sum?
    - m90 4y ago
      Theres go mod tidy, which does exactly that.
      - omginternets 4y ago
        Does that clear out go.sum too? I thought it only affected go.mod ...
deleted 4y ago
[deleted]
ricardbejarano 4y ago
I like echo very much, specially for its middleware engine.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
Philip-J-Fry 4y ago
This doesn’t look all that impressive to me. One of the greatest things about the standard library HTTP handlers is that you have an io.Writer that you can do whatever you want with. It looks like this library removes the flexibility of that and instead provides a worse API to the user. I feel like they could still have a good module here if the performance gains are independent of the actual handler API. I don’t want “frameworks”, I want composable modules that I can mix and match. Things should be small and simple.
- abdusco 4y ago
  > One of the greatest things about the standard library HTTP handlers is that you have an io.Writer that you can do whatever you want with. > It looks like this library removes the flexibility of that and instead provides a worse API to the user. You can get to the stdlib http.ResponseWriter and http.Request with Response() and Request() methods
deleted 4y ago
[deleted]
revskill 4y ago
This is the library i use when i use Golang to build API. Simple and just works though i have NO experience with Golang. Beautiful work.
schmooser 4y ago
I used Echo for one of my projects few years ago. I don’t remember which version it was, but authors (Labstack) were releasing major versions like every year or so, after two migrations I found myself in need to migrate again. That project is in maintenance mode, so still uses old Echo, but if I ever need to migrate, that would be to Fiber.
- deleted 4y ago
  [deleted]
m000 4y ago
I worked very briefly with echo and was left seriously unimpressed. I was called to fix a bug where some url paths were not processed properly. It turned out that echo does not use the standard Go net/url functions for url decoding, but uses some esoteric, roll-your-own, non-standard-compliant implementation instead. Cutting corners around web standards is ill-conceived minimalism, suitable only for hobby projects.
tmpz22 4y ago
Please read the underlying benchmark code before evaluating this web framework as a "High performance" option. People are welcome to create whatever abstractions they want but I highly encourage new golang users to experiment without web frameworks using the standard library and minimalist libraries like gorilla/mux, sqlx, and squirrel, to compose your web applications with much less of a headache.
ram_rar 4y ago
I have used echo in the past to build control plane services for a famous logging company. Its great to get things up and running closer to production quality. My team was easily able to extend this framework and add auditing and integrations with other internal tools within the company. The one thing, authors could build as a differentiating factor is to provide openapi spec support out of the box. I have not seen many golang web frameworks provide first class support for building using openapi spec.

91 points by kiyanwang 4y ago

I just started using echo for a personal project - just a boring old server rendered webapp. Overall, it has some niceties which can save a lot of time. The documentation and cookbook cover the most common usage patterns. I like that it doesn't enforce too many conventions unlike Rails/Django. P.S: Logging is still a bit of mess in the Go ecosystem!

Cwizard 4y ago
Could you elaborate why logging is a mess in the Go ecosystem?
- fredrikholm 4y ago
  Wouldn't call it a mess, but there is less consensus amongst the community. Logging is one of the areas where there is no established standard. That said, Zap (by Uber) has proved itself and is a solid choice. We've used it in several projects at [company], handling very high loads.
  - gabereiser 4y ago
    Didn't the Go team say that there's a logging interface and that's where they are going to leave it. If you want more robust logging, you can add it. log.New() is for that purpose. If you want a struct-log, you'll have to define one for your needs. Logging is very environment specific. What I log to the console locally is different from what I log to, say, AWS CloudWatch in production. I think the stance on logging by the core Go team is the right way to go about it. Just provide a basic logger, an interface, and let the projects determine how they want to route those logs and what kind of data should it include.
    - qzio 4y ago
      Can you provide a link to this interface? The log package in stdlib doesn’t let you specify levels, just a Printf unless Iam mistaken, and it is not an interface I believe.
      - gabereiser 4y ago
        Ah, it's not an interface but a struct. My mistake. The syslog part of the log package allows you to specify the priority. https://pkg.go.dev/log/syslog@go1.19#Priority https://pkg.go.dev/log/syslog@go1.19#Priority

fileeditview 4y ago

I've used Echo on a few occasions and it is nice little Go web framework.. or more a library.. it doesn't bringt much extra fuzz. The reason why I chose Echo among all of the Go web "frameworks" was that it didn't use FastHTTP, which is used by many (most?). I however ran into a (simple) pattern of endpoints a long time ago that you could not be matched by FastHTTP and realized the speed improvements may not be worth it. There was also no http2 support back then. Too many people just look at micro-benchmarks for these frameworks.

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.

molly0 4y ago

For someone (me) that started to get into Go 4 days ago. What is the difference between a framework like this and Gin?

xvello 4y ago
Gin and Echo cover similar feature scopes (the HTTP plumbing around your business logic, that you write in handler functions), but I chose Echo for my project[1] because: - it ships a pretty extensive collection of middlewares that will get you to 80% faster - the documentation[2] is really well written and accessible to new web developers: most "must have" features have a cookbook page, so you don't have to google for blog posts. - it does indeed use a custom handler function signature, but in my opinion this one is better (returning errors instead of handling them locally in each handler). You can still use handlers and middlewares written for other frameworks (for example the great statigz[3] handler) through the `echo.WrapHandler` and `echo.WrapMiddleware` functions [1] https://github.com/letsblockit/letsblockit https://github.com/letsblockit/letsblockit [2] https://echo.labstack.com/guide https://echo.labstack.com/guide [3] https://github.com/vearutop/statigz https://github.com/vearutop/statigz
- molly0 4y ago
  Thank you for this answer, it’s great to get tips like this when starting with a new language.
fredrikholm 4y ago
No real difference. They both deviate from standard interfaces (eg. https://pkg.go.dev/net/http#Handler https://pkg.go.dev/net/http#Handler) and do their own thing. This is fine, but unidiomatic. The Go community steers towards 'one way of doing things', meaning that packages that don't reuse established interfaces tend to be less popular compared to the ones that do (gorilla, chi, or just std).
- molly0 4y ago
  Thanks!

uo21tp5hoyg 4y ago

Their rendering handling seems to be a lot better than gofiber's[1] which downloads nearly 1,000 packages and sadly that ruled it out as a viable framework when I was looking for web frameworks to use. [1] https://github.com/gofiber/template/blob/master/go.sum https://github.com/gofiber/template/blob/master/go.sum

deleted 4y ago
[deleted]
m90 4y ago
A package appearing in go.sum does not necessarily mean it's being used. It just means it has been downloaded once, but might have been replaced by some other version at some point.
- salmo 4y ago
  This has bitten me before. A security scanner reported a vulnerability from this that was blocking me from my “use X at work” request. I ended up having to teach the vendor of the tool about go mod. But if you are publishing a “release” I personally think it is good to tidy that up. Even just to prevent misconceptions. No reason to preserve ancient versions and especially failed library experiments.
- omginternets 4y ago
  Is there a safe way to de-bloat go.sum?
  - m90 4y ago
    Theres go mod tidy, which does exactly that.
    - omginternets 4y ago
      Does that clear out go.sum too? I thought it only affected go.mod ...

deleted 4y ago

[deleted]

ricardbejarano 4y ago

I like echo very much, specially for its middleware engine.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

Philip-J-Fry 4y ago

This doesn’t look all that impressive to me. One of the greatest things about the standard library HTTP handlers is that you have an io.Writer that you can do whatever you want with. It looks like this library removes the flexibility of that and instead provides a worse API to the user. I feel like they could still have a good module here if the performance gains are independent of the actual handler API. I don’t want “frameworks”, I want composable modules that I can mix and match. Things should be small and simple.

abdusco 4y ago
> One of the greatest things about the standard library HTTP handlers is that you have an io.Writer that you can do whatever you want with. > It looks like this library removes the flexibility of that and instead provides a worse API to the user. You can get to the stdlib http.ResponseWriter and http.Request with Response() and Request() methods

deleted 4y ago

[deleted]

revskill 4y ago

This is the library i use when i use Golang to build API. Simple and just works though i have NO experience with Golang. Beautiful work.

schmooser 4y ago

I used Echo for one of my projects few years ago. I don’t remember which version it was, but authors (Labstack) were releasing major versions like every year or so, after two migrations I found myself in need to migrate again. That project is in maintenance mode, so still uses old Echo, but if I ever need to migrate, that would be to Fiber.

deleted 4y ago
[deleted]

m000 4y ago

I worked very briefly with echo and was left seriously unimpressed. I was called to fix a bug where some url paths were not processed properly. It turned out that echo does not use the standard Go net/url functions for url decoding, but uses some esoteric, roll-your-own, non-standard-compliant implementation instead. Cutting corners around web standards is ill-conceived minimalism, suitable only for hobby projects.

tmpz22 4y ago

Please read the underlying benchmark code before evaluating this web framework as a "High performance" option. People are welcome to create whatever abstractions they want but I highly encourage new golang users to experiment without web frameworks using the standard library and minimalist libraries like gorilla/mux, sqlx, and squirrel, to compose your web applications with much less of a headache.

ram_rar 4y ago

I have used echo in the past to build control plane services for a famous logging company. Its great to get things up and running closer to production quality. My team was easily able to extend this framework and add auditing and integrations with other internal tools within the company. The one thing, authors could build as a differentiating factor is to provide openapi spec support out of the box. I have not seen many golang web frameworks provide first class support for building using openapi spec.