3 ms·

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

by molly0 4y ago

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!
- verdverm 4y ago
  Gorilla is no longer maintained I would argue that 'one way of doing things' is really at a much lower level, not at the package or module level. That was tied to "one way to loop, one way to place curly braces" Extending this idea to modules is not actually in line with how the GO team and community works.
  - fredrikholm 4y ago
    > Gorilla is no longer maintained Ah, I wasn't aware! It was heavily used a few years ago. > Extending this idea to modules is not actually in line with how the ... community works This is not my experience (with the community). Packages that heavily reuse common interfaces (combinations of io.Reader|Writer|Closer|Seeker, http.Handler, http.ResponseWriter etc) tend to be more popular and recommended than packages that invent their own interfaces. That is, unless the recommendation is just 'stick to the std', which has been a knee-jerk reaction from the community (reddit, slack) for a lot of problems, especially concerning new comers.

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

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

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!
verdverm 4y ago
Gorilla is no longer maintained I would argue that 'one way of doing things' is really at a much lower level, not at the package or module level. That was tied to "one way to loop, one way to place curly braces" Extending this idea to modules is not actually in line with how the GO team and community works.
- fredrikholm 4y ago
  > Gorilla is no longer maintained Ah, I wasn't aware! It was heavily used a few years ago. > Extending this idea to modules is not actually in line with how the ... community works This is not my experience (with the community). Packages that heavily reuse common interfaces (combinations of io.Reader|Writer|Closer|Seeker, http.Handler, http.ResponseWriter etc) tend to be more popular and recommended than packages that invent their own interfaces. That is, unless the recommendation is just 'stick to the std', which has been a knee-jerk reaction from the community (reddit, slack) for a lot of problems, especially concerning new comers.