Gadget: A smallish web framework for Go

http://redneckbeard.github.io/gadget/

by redneckbeard • 13 years ago

97 50 13 years ago

redneckbeard.github.io

acron02• 13 years ago

Looks smart! Curiously, any reason you chose not to use Revel?

redneckbeard5• 13 years ago

Two reasons:

1) I didn't want routes in a text file. This is whiny, I know. Just a personal preference. 2) Go is the only programming language that has held my attention long enough to actually finish a fairly usable framework. Writing a framework is a good exercise in software design, so I felt like I had to use the opportunity.

acron02• 13 years ago

I totally agree with you on routes in a text file. Are you gonna go 'batteries included' with Gadget, or keep aiming for that middle ground?

I ask because I am looking to put my weight behind a framework and am undecided, but not at all attracted to Revel...

ds_• 13 years ago

Or martini? I liked the look of martini but have not delved deep enough to make an informed decision. Might pick Go for my next side project...

saiko-chriskun• 13 years ago

Just came back from a go meetup where I met the developer of martini actually, I think it's a really well thought-out framework :)

mmgutz• 13 years ago

The only thing I really see in martini over plain gorilla mux is dependency injection which has a reflection cost. Once you peel back the Classic mode, which I advise not using except for trivial projects, your code base is about the same. I'm sticking with gorilla.

keda• 13 years ago

Unlike Revel, you don't seem to have watch setup for .go files, which make sense since you want to keep it smallish. Curious on how other gopher trigger app restart from their editor of choice. Anyone have insight for setting up VIM+Tmux for Golang development that enable app restart from single key press? Sample .vimrc will be great.

altf4• 13 years ago

I use Grunt [1] and (especially) grunt-contrib-watch [2] for this. Using Grunt also has the benefit of automatically recompiling CSS files and/or concatenating JS files etc. But your mileage may vary, of course.

[1] http://gruntjs.com/ [2] https://github.com/gruntjs/grunt-contrib-watch

codegangsta5• 13 years ago

I totally built a watcher command line app and ditched it because this was more convenient :)

https://github.com/codegangsta/dotfiles/blob/master/vim/vim/...

redneckbeard5• 13 years ago

Recompiling and restarting the server has yet to become a bottleneck in development for me, or at least it hasn't caused enough friction or irritation to compel me to add something using fsnotify or other solutions. If you told me that you were very interested in using the framework but the lack of this feature was a barrier to adoption, I'd definitely think harder about it.

RBerenguel• 13 years ago

I write plain handlefuncs, but so far I have a pretty easy to remember command to restart the server for local development (works as well in Acme, where I'm writing most of my go code as in emacs, where I write templates and vim, where I usually just make really quick edits.) It's Cmd-Tab C-c [up] enter.

Just trying to express the same redneckbeard said: until it is a very thin bottleneck, this should be no problem.

rsenk330• 13 years ago

I've recently used Russ Cox's devweb for this:

https://code.google.com/p/rsc/source/browse/devweb/

AYBABTME• 13 years ago

Adding a watch system is not very complicate using `fsnotify`, I've done it for a toy blog app, so that it watches the `/posts/` folder for new Markdown, and the `/templates/` folder for modified templates.

I've even made it rewrite (eradicate) templates that don't compile (threats).

https://github.com/aybabtme/brog/blob/master/brogger/templat...

At this point, the code is kind of messy, so please overlook that. I also have a bare deployment on an t1.micro : http://www.antoine.im/

bwooceli• 13 years ago

As a "non programmer" this excites me greatly. I learned Python by way of Django and can't wait to stand on some Go giant shoulders.

voidlogic7• 13 years ago

I would love to hear why I would want something like this, or revel, or goweb, over: angular.js + Go web-service (net/http + Gorilla).

redneckbeard5• 13 years ago

I just don't understand the argument that we should all just use HandlerFuncs for everything. Python and Ruby have stdlib HTTP facilities that are pretty good. They aren't nearly as nice as net/http, but you could totally build websites with them. People still have written lots of web frameworks, because it makes their lives easier. It lets them express programs in a simpler, higher-level way. I feel like this is even more valid now in 2013 since nearly anyone who's building websites has done so with one of those high-level frameworks, and they expect a similar experience.

Lots of people have abandoned Rails for Sinatra, or Django for Flask. That's totally cool, and there are good reasons to do so. There are also very good and obvious reasons to use something that further abstractions common patterns if the software you are building conforms reasonably well to those patterns.

voidlogic7• 13 years ago

feel like this is even more valid now in 2013 since nearly anyone who's building websites has done so with one of those high-level frameworks, and they expect a similar experience.

But in 2013 do I really want to use server side HTML tempalating? Why not just connect a webservice to a HTML/JS presentation layer like I am suggesting? If all you are doing is building a webservice then the abstractions beyond net/http + Gorilla are not buying you much IMHO, but they do come at quite a performance cost: http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...

My first couple Go web applications did things the html/template way and were structured on the way I used to go JSF applications- but since I switched to the above approach my projects have been better performing, faster to develop , better scaling and easier to maintain. As we all know, we seldom get all those things in one technology choice without trade-offs.

codegangsta5• 13 years ago

If you don't want it then you don't want it. Both Gadget and Martini pretty clearly outline the value that they bring to the table. If that value proposition does not win you over then these frameworks are not for you.

I personally have seen a great improvement in code simplicity, readability, and overall DRYness when projects are written using Martini.

Choosing a framework isn't about following some sort of socially acceptable way to build your web apps. Just build them! If a framework solves a problem for you then use it, otherwise keep using net/http handlers.

voidlogic7• 13 years ago

I'm glad you like these frameworks, and I not telling anyone not to use them. Like I said, I was just interested in hearing why I would want something like these frameworks which focus on server side templating, over a HTML/JS frontend + webservice approach. If you are just writing a webservice I think using Gorilla in addition to net/http is pretty much perfect.

bernatfp2• 13 years ago

As a fan of Flask/Bottle/Sinatra/Express style web frameworks I miss a Go framework that works in a similar fashion. Don't know of any better way to prototype APIs so quickly and with such a small mental effort.

Edit: Just discovered [Martini](https://github.com/codegangsta/martini), that's exactly what I wanted.

codegangsta5• 13 years ago

Have you seen Martini?

https://github.com/codegangsta/martini

bernatfp2• 13 years ago

Yeah just after posting my comment.

BTW, great work, that's exactly what I was looking for.

recuter2• 13 years ago

I'm kind of amazed at the SLOC, ~600 lines for the whole thing. Flask is much bigger and depends on Werkzeug (~20K?), heck even Bottle doesn't come in under 1,000 lines. That is incredibly attractive.

gregchapple• 13 years ago

+1 for Martini. Spent some time looking for a decent framework like this, and was delighted when I discovered it.

taude• 13 years ago

Thanks. As a Flask user myself, and sort-of interested in Go, I'm going to take a look at this. Thanks.

optymizer3• 13 years ago

"Handlers are invoked via reflection"

That's where I say NO. go's reflect package is slow and a nightmare to use. Go's JSON parser, which uses reflect, is 2.5x slower than Node.js (in my own benchmarks [1]). And Go 1.1 was 3.5x worse that Node.js at parsing JSON. Again, those are my benchmarks, but they seem consistent with what other people are finding (from my Googling around).

I would not make this trade off, I would not use reflect on EVERY request, just so that my request handlers are compatible with http.HandleFunc. It almost seems silly to do that. That's why other frameworks (like Revel) are using custom Request objects.

However, I do understand why the author is emphasizing this feature. If your handlers are incompatible with http.HandleFunc (i.e. if they take a custom Request object), you need your own Router which invokes the handlers, and you need your own ServeMux, so you end up giving up on a lot of functionality from net/http. That's why Revel has a ton of custom objects that mirror what net/http has and it proxies method calls.

So you keep wondering: "why the hell am I writing so much seemingly unrelated code? I just want to add a 'user' property to each request, but now I've coded so many struct's and created so many files". It makes you feel unproductive and it bloats the code.

Again, I've made my choice, but you should be aware of such caveats and, of course, benchmark things yourself.

1) My benchmark results. For some charts, higher is better, for others, lower is better. Use your judgement. http://goo.gl/xfWFXo

losvedir• 13 years ago

It looks really slick, and I'm considering switching over a go-backed JSON API to an Ember app I'm building to use it.

How's the performance? I'm a little afraid of the "reflection" boogeyman, but I don't have any experience to say what kind of impact we're talking about here.

I'm coming from Rails day-to-day, and a very light, compiled Go web backend is a refreshing change of pace. I'm leery of giving up the simplicity of net/http, but if it stays small maybe it's the way to go. Right now I'm popping in gorilla toolkit, though, so if martini is as "light touch" as that, I'd be up for using it.

re-l• 13 years ago

Damn, routers and controllers are not an issue in Go, models — is. I belive, that rich middleware between rich backend and rich client does matter. It isn't manipulating with html views, it's working with data. It's a proxy layer. And unfortunately, I don't see it in the modern Go web frameworks. Anyway, it's a great job.

elithrar• 13 years ago

You could easily use something like gorp (https://github.com/coopernurse/gorp) alongside Gadget (or any other Go web framework). Like Flask, the use of SQLAlchemy isn't innately tied to the framework.

kin• 13 years ago

This is an irrelevant comment but I love the name. I'm assuming it's a play on the Go-Go-Gadget line?

Gadget: A smallish web framework for Go

Related Stories