Choosing a framework

[Tim Uckun]

I am in the process of learning go and decided to do it by writing a (mostly) API based web site. I have been doing some research and have found the following.

Revel: https://revel.github.io/

GoBuffalo: https://gobuffalo.io/

Iris: https://iris-go.com/

In addition there are "toolkits" like chi and buffallo but it looks like eventually I will need pretty much all the things these frameworks provide and there are so many competing projects that provide logging, configuration, routing, middleware etc that it would take me a long time to do all the research and find the ones most suitable for me.

I understand that there is quite a bit of controversy with iris so I probably won't go with that one but does anybody have any experience with the others they are willing to share?

[Rodolfo]

https://echo.labstack.com/

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Uckun]

Do you have experience with this? Can you say a couple of words about it?

[Shawn Milochik]

This topic has been discussed many times on this list. Do a search and you'll see a lot of great points.

My opinion is that you should use the standard library, and only reach for individual components when it would provide a significant advantage. Do not use any "framework." Like Go's object-oriented design which affords embedding and not inheritance, you should plug in components as necessary to your code. Don't write your code to conform to the opinions of a framework. For example, if you want to use a plugin for websockets, sessions, or routing, that's fine. But don't look for a Django/Rails replacement.

[Florin Pățan]

Given your list of choices, I would go for Buffalo as it's probably the closest you can get to an idiomatic Go code base while not having magic in the code and still be able to understand what's happening when things go wrong.

As others have recommended, also try writing your code without the use of a framework, just so that you understand the trade-offs you are doing vs using a framework.

Go is rather enjoyable to use without any framework and far to often I see people having: "I'm new to Go, I don't know how to program in this thing. Btw, I'm using X framework" when in fact their question is not even remotely related to the framework (and sometimes Go itself).

[Tim Uckun]

On Monday, September 11, 2017 at 12:56:40 PM UTC+12, Florin Pățan wrote:

Given your list of choices, I would go for Buffalo as it's probably the closest you can get to an idiomatic Go code base while not having magic in the code and still be able to understand what's happening when things go wrong.

As others have recommended, also try writing your code without the use of a framework, just so that you understand the trade-offs you are doing vs using a framework.

Go is rather enjoyable to use without any framework and far to often I see people having: "I'm new to Go, I don't know how to program in this thing. Btw, I'm using X framework" when in fact their question is not even remotely related to the framework (and sometimes Go itself).

I understand the sentiment but I am really confused by this advice. Are you saying I should write everything myself? My own CSRF implementation, my own authentication scheme, my own rate limiter, my own jwt implementation, my own logger etc? If that's the case I'll be honest and say I won't build this thing in go. 

If that's not the case and it is OK to go to github, do some research, read all the readmes, and then try and assemble a pack of libs written by other people into my own framework well that too seems a little unreasonable to me.  Surely somebody has done the work and already put together a solid stack which is known to be of decent quality and works well together. 

One last point. When you assemble parts together yourself the thing that is most likely to be painful is getting help. Many of the projects on github don't have mailing lists so you have to communicate via tickets which I find to be cumbersome. Some very popular projects I have looked at have over 100 open tickets most of which don't even have acknowledgements that the author read the thing. If you ask for help the answer will probably turn into a finger pointing exercise because the author may think it's some other part of the stack that's causing a problem. With a framework you only have one place to ask for help.

[Shawn Milochik]

On Sun, Sep 10, 2017 at 10:05 PM, Tim Uckun <timu...@gmail.com> wrote:

I understand the sentiment but I am really confused by this advice. Are you saying I should write everything myself? My own CSRF implementation, my own authentication scheme, my own rate limiter, my own jwt implementation, my own logger etc? If that's the case I'll be honest and say I won't build this thing in go. 

If that's not the case and it is OK to go to github, do some research, read all the readmes, and then try and assemble a pack of libs written by other people into my own framework well that too seems a little unreasonable to me.  Surely somebody has done the work and already put together a solid stack which is known to be of decent quality and works well together. 

One last point. When you assemble parts together yourself the thing that is most likely to be painful is getting help. Many of the projects on github don't have mailing lists so you have to communicate via tickets which I find to be cumbersome. Some very popular projects I have looked at have over 100 open tickets most of which don't even have acknowledgements that the author read the thing. If you ask for help the answer will probably turn into a finger pointing exercise because the author may think it's some other part of the stack that's causing a problem. With a framework you only have one place to ask for help.

No, nobody is telling you to write your own CSRF, authentication, rate limiting, etc. You can if you want to, or if you think it's a good use of your time, or you're unhappy with existing implementations.

No, nobody is telling you to assemble your own framework, either. That's the whole point. Use no framework. Just write your code and plug in bits as needed. That's the Go way. Embedding, not inheriting. 

Yes, assemble bits from other small projects. Wouldn't you rather have a database driver from a database expert, an authentication system from a security expert, and no restrictions regarding which you can mix and match?

As for who you can complain to when things don't work, all I can say is that if you're a programmer, you're responsible for your own code. If you want someone else to be responsible for it, then hire someone to write it for you. I don't say it this way to be offensive. It's the simple truth. 

[Tim Uckun]

I will simply point out that go seems to be alone in this regard. All other languages that I know and have used have embraced the idea that it's OK to assemble various functionalities in a useful framework which one can deploy without too much effort. 

[Henry]

Actually, there is nothing in Go that prevents you from using any kind of frameworks. You are free to use whatever you wish.

Go provides a more complete standard library for web development than many other programming languages. While in other languages you have to rely on frameworks, in Go, building your own framework isn't that difficult.

That being said, just choose whatever suits your needs.

[Henrik Johansson]

Maybe it is better nowadays but at least last time I tried a bigger framework the first thing that happened was I had to either change logger or wrestle with how the framework did it's logging.

I would from experience in both Go and other languages (mostly Java, Spring is not your friend) very much recommend choosing a smaller set of libraries that each do a limited thing. It will hurt more than it is worth in the long run.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Sam Whited]

Here is a list of useful components that I sometimes reach for when I
need to do something in HTTP land that requires that I leave the comfort
and safety of the standard library but don't want to get locked into a
"framework". There may be better implementations of some of these, but
the ones listed here are often "good enough" in my book:

- https://godoc.org/golang.org/x/net/xsrftoken
- https://godoc.org/golang.org/x/oauth2
- https://godoc.org/golang.org/x/oauth2/jwt
- https://godoc.org/golang.org/x/oauth2/jws
- https://godoc.org/golang.org/x/net/netutil (contains a method for
limiting simultaneous connections)
- https://godoc.org/golang.org/x/net/websocket (though I've heard that
some people prefer https://godoc.org/github.com/gorilla/websocket)
- https://godoc.org/golang.org/x/time/rate (rate limiter)
- https://godoc.org/golang.org/x/net/trace (request tracing)
- https://godoc.org/golang.org/x/text/secure/precis (Unicode safety)

—Sam

[Kevin Powick]

Asked and answered many times in this group and in another popular Go forum:

https://forum.golangbridge.org/search?q=framework

Another collection of Go frameworks, tools, packages (libs) can be found in the following GitHub repo:

https://github.com/avelino/awesome-go#web-frameworks

There are a lot of good frameworks, if that's what you want, but jumping into a framework when you're just learning Go may be premature, especially since Go has such an extensive standard library.

https://golang.org/pkg/

If you do use a framework, the one that is "best" is the one that is not only well supported, but appeals to your own development philosophy.  Just because a framework is popular, doesn't mean it will be a joy for "you" to use, or even fit your particular use case.

My first foray into frameworks for Go was the, at the time, hugely popular "Martini" web framework.  https://github.com/go-martini/martini

It was by far the leader in web frameworks when I first started with Go.  However, even the author of that framework later wrote a blog post admitting that he created Martini when he was not a proficient Go developer, that the design was not idiomatic Go, and it should probably not be used.

https://web.archive.org/web/20151031022001/http://codegangsta.io/blog/2014/05/19/my-thoughts-on-martini/

Below is a link to the article that prompted the above blog. (The original link in the blog post does not seem to work):

https://stephensearles.com/three-reasons-you-should-not-use-martini/

Today, there are better alternatives, but you have to research them; there is no "best".  With regard to the list of frameworks you've come up with already, there's one I wouldn't touch, one that I think is too bloated, and one I might consider.  Again, these are for personal reasons, so I suggest you learn Go more fully before making a decision.

--

Kevin Powick

[woosley. xu.]

Personally when I started my project I chose to use a framework.  I think it is ok to start with frameworks as long as you know what framework should do, what key concepts should be handled when dealing with Web app. Maybe Go provides all those solutions with standard pkgs, but if a framework can glue them all together, why not try use it.

What I will not use is Django/ROR style framework, they are 2 heavy and you have to learn their way of layouting the project.  I'd say choose a nimimal framework to start with, it is not a big issue.

Currently I am using echo, which seems to be working well.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

woosley.xu.    http://twitter.com/redicaps

[Vikram Rawat]

I am trying to learn golang too. and I have never ever build a website. All the experience that I have is by building SHINY R dashboards.I tried almost all the framework. But I liked REVEL. Because speed and concurrency is not my concern I just want to write simple database web applications. 

You should definetly check that out. It's the best I have come across. It creates the entire directory structure for you at one command. All you have to do is change the code peice by piece.

And there is another project called VECTY. But I mailed them and they told me it's not documented yet. and it could have bugs.

So trust me try revel for a few days after that choose whatever you want to.... 

[Jim Ancona]

On Thu, Sep 14, 2017 at 1:28 AM, Vikram Rawat <vikram...@gmail.com> wrote:

And there is another project called VECTY. But I mailed them and they told me it's not documented yet. and it could have bugs.

 

Vecty (https://github.com/gopherjs/vecty) uses Gopherjs and runs in the browser, so it used for different things than the server-side frameworks like Revel.

[Vikram Rawat]

Thanks for the tip! But he is a newcomer and so am I. Tell us can we learn it. Is it documented anywhere. That's exactly what i told him.

I would love to try vecty. But right now we can't figure out how to try it.

14-09-2017 9:14 pm को "Jim Ancona" <j...@anconafamily.com> ने लिखा:

[Tim Uckun]

At this point haven't you just built your own framework? You looked around, did some research, read a whole of documentation and decided that this set of components work well together and do what  you want. 

It seems to me that a framework is the exact same thing except that somebody else has compiled a list of components and then wired them up in a coherent way and hopefully provided one set of documents to explain it all. Hopefully there is also a single place to get help too.

[john howitt]

One of my reasons for moving to Go was to escape from frameworks which in my opinion are a fashion statement not a technology. Slightly mangling the saying about Regular expressions "I have a problem learning Go", "OK use a framework", "Now i have two problems", "You can also use and ORM", "Ah now i have three problems".

On Sunday, September 10, 2017 at 12:51:40 AM UTC+1, Tim Uckun wrote:

[Shawn Milochik]

On Fri, Sep 15, 2017 at 7:50 AM, john howitt <parl...@gmail.com> wrote:

One of my reasons for moving to Go was to escape from frameworks which in my opinion are a fashion statement not a technology. Slightly mangling the saying about Regular expressions "I have a problem learning Go", "OK use a framework", "Now i have two problems", "You can also use and ORM", "Ah now i have three problems".

Ha ha! Of course, regular expressions rock. But I definitely agree, frameworks and ORMs are absolutely a net negative for maintainability -- the only measure that matters to me, as all others only contribute to it.