Live data from Hacker News

Buffalo – MVC Web Framework for Go

gobuffalo.io

21–30 of 46 posts

Re: Buffalo – MVC Web Framework for Go

#21
post #9
post #4

I always defer to frameworks when working on any project, large or small, so this looks really cool to me as we have been debating on breaking out some of our high volume components into microservices at work and Go is an option. For large projects, using a framework and writing code the way the framework wants you to means that it's much easier to get new team members up to speed, meaning they contribute sooner and…

Depending on how micro your microservice is and if it really is high volume (not sure what high volume means to you) then I would recommend just stick with the standard library to start and grabbing other libs as you need. I wrote a simple internal microservice handling ~400k req/s at peak with no framework and it works great. I can see the appeal of the framework in getting something up and running really fast with…

I think that it depends on the size and number of your projects. The fact that Go has the equivalent of Sinatra/Flask/Express in the standard library is really cool, but that isn't always what you need.

At work we have several dozen applications in service for multiple customers, and almost every single one needs more than that: authn, authz, I8n, DB schema management, a REPL for support work (debugging and data amends), standardized layouts and components from easy switching between projects etc. etc. If we were a larger org with even more applications we would probably benefit from microservices, but actually, Rails-style monoliths are exactly the right fit for us. If we didn't have a framework we'd have to pick a set of components and maintain the glue code to stitch them together, then re-use across products: IOW, we'd end up making a framework if there wasn't one already. At my last job, that actually happened.

Re: Buffalo – MVC Web Framework for Go

#22
post #9
post #4

I always defer to frameworks when working on any project, large or small, so this looks really cool to me as we have been debating on breaking out some of our high volume components into microservices at work and Go is an option. For large projects, using a framework and writing code the way the framework wants you to means that it's much easier to get new team members up to speed, meaning they contribute sooner and…

Depending on how micro your microservice is and if it really is high volume (not sure what high volume means to you) then I would recommend just stick with the standard library to start and grabbing other libs as you need. I wrote a simple internal microservice handling ~400k req/s at peak with no framework and it works great. I can see the appeal of the framework in getting something up and running really fast with…

We know that standard library is enough But there is always need for a framework if you do the same thing over and over again. The consensus in the GO community seems to be that you create from scratch every-time the same handlers, utilities etc. And practically we have ended up with everyone having their own in-house framework. There is nothing wrong with not wanting to create the same helpers every time or not wanting to have your personal framework.

Saying that the standard library is all you need is like saying that you don't need the standard library either, Go's Keywords are all you need.

Re: Buffalo – MVC Web Framework for Go

#23
post #9
post #4

I always defer to frameworks when working on any project, large or small, so this looks really cool to me as we have been debating on breaking out some of our high volume components into microservices at work and Go is an option. For large projects, using a framework and writing code the way the framework wants you to means that it's much easier to get new team members up to speed, meaning they contribute sooner and…

Depending on how micro your microservice is and if it really is high volume (not sure what high volume means to you) then I would recommend just stick with the standard library to start and grabbing other libs as you need. I wrote a simple internal microservice handling ~400k req/s at peak with no framework and it works great. I can see the appeal of the framework in getting something up and running really fast with…

[deleted]

Re: Buffalo – MVC Web Framework for Go

#24
post #11

Sounds like Buffalo is omakase?

Nothing can be omakase in Go. The language disallow it, unless you completely opt out of its type system. But then, what's the point of using a statically typed language? Go is built in a way that forbids writing abstractions. When I say forbid it really does forbid it. Even C is more expressive. Buffalo isn't a framework, unless a router + few bells and whistles is now considered "framework".

Go is built in a way that forbids writing abstractions.

There are lots of abstractions in Go - e.g. structs, interfaces, goroutines, channels. It may not have all the abstractions you're used to (e.g. inheritance, generics), and might still be lacking in areas, but your statement is extreme hyperbole and not useful.

As to whether something is a framework or not, why is this important to you?

Re: Buffalo – MVC Web Framework for Go

#25
post #16

Go is such an easy language as it is, these kinds of frameworks just encourage amateur developers to skirt by with minimal understanding of what they're really doing. An MVC framework sounds like a great personal hacking project for fun, but I would beware of advertising anything like it for professional use.

The further problem is the resulting community. Interviewing for Go devs is going to become a pain.

> Interviewing for Go devs is going to become a pain

Might I ask why?

Re: Buffalo – MVC Web Framework for Go

#27

Sounds like Buffalo is omakase?

Go is omakase.

"But there's a fine line between a friendly suggestion and a belligerent diner. That line is usually exposed when the suggestion is declined: "I'm sorry, but hotdogs don't really fit our sushi menu, and while you may not care for unagi, we picked it for a reason. But thanks for the suggestions!". If only most arguments about the menu would stop there.

But they don't, do they? They usually carry on and on. BUT I REALLY DON'T LIKE UNAGI!!! IT'S OFFENDING MY TASTE BUDS THAT IT'S PART OF THE DEFAULT COURSE SETTING. TAKE IT OOOOOOFFFFF!! Okay, buddy, sit down and have a sake." http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...

Don't get me wrong, I love the language, however, I think about this everytime I read about language proposals being nuked (cough generics).

Re: Buffalo – MVC Web Framework for Go

#28
post #16

Go is such an easy language as it is, these kinds of frameworks just encourage amateur developers to skirt by with minimal understanding of what they're really doing. An MVC framework sounds like a great personal hacking project for fun, but I would beware of advertising anything like it for professional use.

The further problem is the resulting community. Interviewing for Go devs is going to become a pain.

I think most devs would have the flexibility of mind to adjust to whatever framework (or whatever ad-hoc, informally-specified implementation of half a framework) you use in-house. Many of the frameworks are not very different and lean heavily on the stdlib anyway, this is not rocket science, frameworks have different uses and strong points and the community does not have to be divided in religious war between different frameworks or framework advocates and the church of the one pure stdlib.

These are tools, not competing world-views.

Re: Buffalo – MVC Web Framework for Go

#29
I think in practice most of the time, you dont need a framework for webapps in golang. A simple http handler with json / templating etc output is very simple to write. The net/http package is very powerfull, but still has a lean api.

I do use https://github.com/urfave/negroni for routing. But otherwise i just use the http package.

Re: Buffalo – MVC Web Framework for Go

#30
post #16

Go is such an easy language as it is, these kinds of frameworks just encourage amateur developers to skirt by with minimal understanding of what they're really doing. An MVC framework sounds like a great personal hacking project for fun, but I would beware of advertising anything like it for professional use.

> with minimal understanding of what they're really doing In my opinion, this is very dangerous. It is always better to understand the inner workings and then write an app, otherwise you just feel you have accomplished something when, in reality, it was just the framework you used and you didn't learn. I am saying this out of experience, when I used to use Django, I didn't understand the difference between GET vs POS…

Good points. And btw, Thanks for those links to your works in Go.
Post reply on HN