Gadget: A smallish web framework for Go(redneckbeard.github.io)
redneckbeard.github.io
Gadget: A smallish web framework for Go
http://redneckbeard.github.io/gadget/
7 comments
Have you seen Martini?
https://github.com/codegangsta/martini
https://github.com/codegangsta/martini
> "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
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
Your benchmark results look very different from that of the web framework benchmark:
http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...
In that benchmark Go's JSON performance is almost 3x higher than that of Node.
Any reasons why there's such a big difference?
http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...
In that benchmark Go's JSON performance is almost 3x higher than that of Node.
Any reasons why there's such a big difference?
I think it's because they're measuring the rate at which Node.js and Go receive requests, process json, and reply as a single metric.
I measured the speed with which Go and Node.js decode/encode JSON, i.e. there is no network and web server involved, just json.Marshal()/json.Unmarshal() vs JSON.parse()/JSON.stringify()
I benchmarked the web server speed separately.
I measured the speed with which Go and Node.js decode/encode JSON, i.e. there is no network and web server involved, just json.Marshal()/json.Unmarshal() vs JSON.parse()/JSON.stringify()
I benchmarked the web server speed separately.
Do you have the source code for your benchmarks? Thank you.
Sure, I updated the spreadsheet with links to the code for each benchmark. BSD license. Please keep in mind these were quick and dirty. If you run any of them, please reply with your findings.
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.
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.
I have not tried this yet, but https://github.com/benbjohnson/megajson
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.
Yup I plan to keep it that way too. I believe there is enough flexibility in Martini to cultivate some great functionality around the martini-contrib repo. There is already some pretty awesome things landing there https://github.com/codegangsta/martini-contrib
Checkout Camping (Ruby) & Squatting (Perl). Both are web microframeworks that aim (when minimised) to fit at or under 4K characters.
Here's the squashed versions of...
- Camping (currently 4.031 kb over 55 lines) - https://github.com/camping/camping/blob/master/lib/camping.r...
- Squatting (currently 3.929 kb over 68 lines) - https://github.com/beppu/squatting/blob/master/lib/squatting...
Here's the squashed versions of...
- Camping (currently 4.031 kb over 55 lines) - https://github.com/camping/camping/blob/master/lib/camping.r...
- Squatting (currently 3.929 kb over 68 lines) - https://github.com/beppu/squatting/blob/master/lib/squatting...
bottle.py might be a better Python comparison, since they're more concerned about being small & standalone.
Yeah just after posting my comment.
BTW, great work, that's exactly what I was looking for.
BTW, great work, that's exactly what I was looking for.
+1 for Martini. Spent some time looking for a decent framework like this, and was delighted when I discovered it.
Thanks. As a Flask user myself, and sort-of interested in Go, I'm going to take a look at this. Thanks.
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.
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
[1] http://gruntjs.com/ [2] https://github.com/gruntjs/grunt-contrib-watch
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/...
https://github.com/codegangsta/dotfiles/blob/master/vim/vim/...
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/
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/
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.
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.
Just trying to express the same redneckbeard said: until it is a very thin bottleneck, this should be no problem.
I've recently used Russ Cox's devweb for this:
https://code.google.com/p/rsc/source/browse/devweb/
https://code.google.com/p/rsc/source/browse/devweb/
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).
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.
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.
> 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.
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.
But in 2013 do I really want to use server side HTML tempalating?
Many people do yes. It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar before I even see the content as json is turned into html, and I'd rather all the logic was server side and a flat page was served to a web client (browser).
I don't agree doing rendering server-side necessarily means a significant performance cost, or is harder to maintain or slower to develop, why do you think that is the case? Caching and a server-side framework can make things far faster and easier, depending on what you are doing, and raw speed of rendering is not often an issue nowadays anyway.
I'm not sure what the test you pointed to there was showing, because using Go to output json could be done with a framework too by just bypassing the framework, in exactly the same way. It hardly seems a relevant test, and there were other issues in those tests when I looked at them previously - like comparing wildcard routes in one test to hard coded ones in another. Comparing bare JSON production with go to JSON production with webgo (do people use webgo?) is hardly very useful or a fair comparison. It would be trivial to make those equal in speed and I suspect the diff will just be down to different routing and/or template rendering. In addition, I don't want clients to see JSON, so the rendering speed of that is pretty irrelevant, what matters to most people is when html finishes rendering.
It would be interesting to hear the reasons behind the string of assertions in your penultimate sentence, are you sure all types of app would benefit equally from your approach? Can you describe the advantages as you see them to this approach?
Many people do yes. It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar before I even see the content as json is turned into html, and I'd rather all the logic was server side and a flat page was served to a web client (browser).
I don't agree doing rendering server-side necessarily means a significant performance cost, or is harder to maintain or slower to develop, why do you think that is the case? Caching and a server-side framework can make things far faster and easier, depending on what you are doing, and raw speed of rendering is not often an issue nowadays anyway.
I'm not sure what the test you pointed to there was showing, because using Go to output json could be done with a framework too by just bypassing the framework, in exactly the same way. It hardly seems a relevant test, and there were other issues in those tests when I looked at them previously - like comparing wildcard routes in one test to hard coded ones in another. Comparing bare JSON production with go to JSON production with webgo (do people use webgo?) is hardly very useful or a fair comparison. It would be trivial to make those equal in speed and I suspect the diff will just be down to different routing and/or template rendering. In addition, I don't want clients to see JSON, so the rendering speed of that is pretty irrelevant, what matters to most people is when html finishes rendering.
It would be interesting to hear the reasons behind the string of assertions in your penultimate sentence, are you sure all types of app would benefit equally from your approach? Can you describe the advantages as you see them to this approach?
>It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar
This is how bad implementations look to users, consider something like Gmail as a counter example however...
>would be interesting to hear the reasons behind the string of assertions in your penultimate sentence
Sure:)
>are you sure all types of app would benefit equally from your approach?
Of course I am not, I didn't make a that claim. I think most typical applications benefit, it has worked well for me. I was asking questions to understand the point of view I don't hold-
> Can you describe the advantages as you see them to this approach?
This is how bad implementations look to users, consider something like Gmail as a counter example however...
>would be interesting to hear the reasons behind the string of assertions in your penultimate sentence
Sure:)
>are you sure all types of app would benefit equally from your approach?
Of course I am not, I didn't make a that claim. I think most typical applications benefit, it has worked well for me. I was asking questions to understand the point of view I don't hold-
> Can you describe the advantages as you see them to this approach?
In this approach:
Performance:
1. Most assets are (server side) static
2. They are pre-gzipped and stored in memory using a little reusable code I wrote.
3. They are extremely cache friendly
Better scaling:
1. Only a fraction of the previous work happens server side... You using your users compute power.
2. You are transfering less data.
Faster to develop/easier to maintain:
1. This way you have two differnt apps that happen to talk to eachother. This makes it easy to replace one or the other.
2. Responsibilities are clearly defined. This makes brining new people up to speed easier and makes thingse asier to test, debug, etc.Thanks for the comments, it'd be easier to read if they weren't styled using pre!
Of course I am not, I didn't make a that claim.
Sorry, I should have phrased that differently as something like - perhaps not all types of app would benefit equally? I wasn't trying to put words in your mouth. I do think it's a little early to start asking why anyone would use server-side logic any more, there is room for both approaches :)
Perhaps if you are serving data which is text-only, static and fits well into json as you describe, and don't mind coding in Javascript, client-side is a better fit. If you have a lot of server-side data and editing/auth requirements (more of a CMS), and depend on heavily nested templates etc, server-side may be a better fit, though I'm sure it's possible to handle every type of website in theory using either system. There is also the question of which language you prefer to work in - personally I'd rather keep JS use to a minimum, as it's pretty gnarly.
Re the separation of concerns, yes this is a valid point and is something you gain from serving an API if you have a complex system, though it is possible to have a back-end behind a traditional web framework too, with one side being the API serving json or whatever and a separate user-facing service serving HTML.
I don't think speed or caching are a big problem with server-side frameworks nowadays though, and I'd rather use a language like Go than JS to produce web apps. Out of curiosity, which client-side frameworks are you using?
Of course I am not, I didn't make a that claim.
Sorry, I should have phrased that differently as something like - perhaps not all types of app would benefit equally? I wasn't trying to put words in your mouth. I do think it's a little early to start asking why anyone would use server-side logic any more, there is room for both approaches :)
Perhaps if you are serving data which is text-only, static and fits well into json as you describe, and don't mind coding in Javascript, client-side is a better fit. If you have a lot of server-side data and editing/auth requirements (more of a CMS), and depend on heavily nested templates etc, server-side may be a better fit, though I'm sure it's possible to handle every type of website in theory using either system. There is also the question of which language you prefer to work in - personally I'd rather keep JS use to a minimum, as it's pretty gnarly.
Re the separation of concerns, yes this is a valid point and is something you gain from serving an API if you have a complex system, though it is possible to have a back-end behind a traditional web framework too, with one side being the API serving json or whatever and a separate user-facing service serving HTML.
I don't think speed or caching are a big problem with server-side frameworks nowadays though, and I'd rather use a language like Go than JS to produce web apps. Out of curiosity, which client-side frameworks are you using?
I think we agree more than we disagree. Maybe we just differ on which approach is our default one. I dislike JS as well and will be switching to Dart on the front end when I feel it is ready.
>though it is possible to have a back-end behind a traditional web framework too.
Sure I think you get a lot of the maintainability pro's this way, but loose on some of the performance ones.
I mostly write systems software (in Go), but when I write webapps I use angular.js (frontend) + Go (backend) + One of many datastores (ex MySQL, Postgre, LevelDB etc)
>though it is possible to have a back-end behind a traditional web framework too.
Sure I think you get a lot of the maintainability pro's this way, but loose on some of the performance ones.
I mostly write systems software (in Go), but when I write webapps I use angular.js (frontend) + Go (backend) + One of many datastores (ex MySQL, Postgre, LevelDB etc)
[deleted]
> This is how bad implementations look to users, consider something like Gmail as a counter example however...
Gmail isn't a counterexample to the "loading" message thing. It manages to be slow on hardware and network connections that are incredibly fast.
Gmail isn't a counterexample to the "loading" message thing. It manages to be slow on hardware and network connections that are incredibly fast.
You have a point, no pun intended. Focusing on serving up tidy endpoints does away with a lot of complexity (I call shenanigans on the performance argument, especially if you're using Go and not Python/Ruby) - the only unsolved technical debt with this approach would be making GoogleBot happy. If you don't need to care about making crawlers happy this can be great...
On the other hand, the complexity you're punting on needs to go somewhere, so now you'll need to muck about with something like Angular to make up for it. Difficult choices. It kind of continuously feels like we're on the edge of Nirvana with this stuff and something perfect in its elegance will emerge. I'm only 24 but this seems like a dangerous siren song to me... maybe we should all know better by this point, eh?
On the other hand, the complexity you're punting on needs to go somewhere, so now you'll need to muck about with something like Angular to make up for it. Difficult choices. It kind of continuously feels like we're on the edge of Nirvana with this stuff and something perfect in its elegance will emerge. I'm only 24 but this seems like a dangerous siren song to me... maybe we should all know better by this point, eh?
Use of gadget/template is totally optional. The _primary_ use case for Gadget is RESTful web services. That's why you can route to a resource, and have the appropriate controller methods hit by the correct HTTP verbs. The reason to provide support for HTML rendering on the server is no different than providing plaintext rendering: it's really really easy. It's almost free.
I'm not sure that angular apps are quicker to develop for the average internal application yet, for example. The primary issue is that we haven't quite figured out patterns to handle business logic via web service in a way that doesn't duplicate effort on server and client side. At least, I haven't seen it yet.
Why do folks downvote civil open-minded discussion? I always assumed downvotes were for bad behavior or trolling. Is there an official position on the use of downvotes?
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.
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.
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.
shameless plug. Martini doesn't even have html template rendering out of the box. I originally built it because I wanted a better experience building webservices for Angular frontends :)
https://github.com/codegangsta/martini
You and I sir, are on the same wavelength
https://github.com/codegangsta/martini
You and I sir, are on the same wavelength
Interesting, I'll have to play with it. Thanks for sharing.
You should consider adding benchmarks to that it is easy to compare martini to net/http. This will let you keep an eye on performance as you work on it and accept pulls.
You should consider adding benchmarks to that it is easy to compare martini to net/http. This will let you keep an eye on performance as you work on it and accept pulls.
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.
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.
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.
Looks smart! Curiously, any reason you chose not to use Revel?
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.
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.
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...
I ask because I am looking to put my weight behind a framework and am undecided, but not at all attracted to Revel...
I would like to go something like "batteries included but not installed." The User interface I have now is a good example of what I mean -- I would prefer to keep everything built around implementing an interface, but it might be nice to provide an "official" authentication implementation as a subpackage.
I've started writing subpackages as they become important to me. The most useful thus far is probably gadget/forms, which is very much inspired by Django forms. I prefer a data validation layer that is independent from or at least very loosely coupled to a model layer.
I've started writing subpackages as they become important to me. The most useful thus far is probably gadget/forms, which is very much inspired by Django forms. I prefer a data validation layer that is independent from or at least very loosely coupled to a model layer.
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...
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 :)
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.
This is an irrelevant comment but I love the name. I'm assuming it's a play on the Go-Go-Gadget line?
Edit: Just discovered [Martini](https://github.com/codegangsta/martini), that's exactly what I wanted.