Revel, high-productivity Go web framework modeled on Play Framework(robfig.github.com)
robfig.github.com
Revel, high-productivity Go web framework modeled on Play Framework
http://robfig.github.com/revel/
38 comments
First congrats for the framework.
Secondly a question :)
Play team solved the compile "problem" of java using a lib from eclipse so it compiles files on the fly. do you have something similar, or do you plan to include something similar? I think compiling on every change you make while developing an app is painful, the biggest problem java frameworks have, excluding Play! of course.
Secondly a question :)
Play team solved the compile "problem" of java using a lib from eclipse so it compiles files on the fly. do you have something similar, or do you plan to include something similar? I think compiling on every change you make while developing an app is painful, the biggest problem java frameworks have, excluding Play! of course.
Yep, having the hot-compile functionality was a major point of this.
Here is a description of how it works: http://robfig.github.com/revel/manual/howrevelworks.html
Basically: In development mode, it runs a proxy (called the "harness") that watches your source for changes and recompiles/restarts your server on the next request, if necessary, using the "go build" tool. The go build process is incremental, so in theory should only recompile packages that have changed (and those that depend on them)
Here is a description of how it works: http://robfig.github.com/revel/manual/howrevelworks.html
Basically: In development mode, it runs a proxy (called the "harness") that watches your source for changes and recompiles/restarts your server on the next request, if necessary, using the "go build" tool. The go build process is incremental, so in theory should only recompile packages that have changed (and those that depend on them)
There is actually a way to do this fully in process. I think Rob Pike initially build this, and it's being used in the App Engine framework (or so I hear...).
Code: http://code.google.com/p/rsc/source/browse/#hg%2Fdevweb
Code: http://code.google.com/p/rsc/source/browse/#hg%2Fdevweb
It looks like he takes the same approach as Revel. From the comments:
// Devweb is a simple environment for developing a web server.
// It runs its own web server on the given address and proxies
// all requests to the http server program named by importpath.
// It takes care of recompiling and restarting the program as needed.
out, err := exec.Command("go", "build", "-o", "prox.exe", rootPackage).CombinedOutput()
Russ Cox, not Rob Pike, built that.
It's not what's used in the App Engine SDK. I believe it was inspired by what we do in the App Engine SDK, though.
It's not what's used in the App Engine SDK. I believe it was inspired by what we do in the App Engine SDK, though.
awesome!
This is a good reason to learn go :)
This is a good reason to learn go :)
This framework could be enough to tip me into a semi serious go powered side project, which i really must get the finger out and do!
How should deployment work for an app created in this framework?
From the "How Revel Works" page it mentions:
Would the final artifact be deployable to google app engine?
How should deployment work for an app created in this framework?
From the "How Revel Works" page it mentions:
>> If the app compiled successfully, it runs the app ...<snip>...
Would the final artifact be deployable to google app engine?
I'm working on adding a "rev package" command to the command-line tool. It will create a zip file of the app and revel source directories, along with a script to run the app.
It needs the source directories since templates and assets are kept within them. Also, it is frequently useful to have access to the source in production, e.g. for sending exception emails.
The goal is to make deployment to a server without a Go environment very easy.
EDIT: To answer your original question: in the current version, you must have a working Go installation to run your Revel app. Then: "rev run import/path/to/app prod". I am pretty sure that it will not work on GAE -- I realize this is an important/valuable use case and will investigate it in the future.
It needs the source directories since templates and assets are kept within them. Also, it is frequently useful to have access to the source in production, e.g. for sending exception emails.
The goal is to make deployment to a server without a Go environment very easy.
EDIT: To answer your original question: in the current version, you must have a working Go installation to run your Revel app. Then: "rev run import/path/to/app prod". I am pretty sure that it will not work on GAE -- I realize this is an important/valuable use case and will investigate it in the future.
Your direction sounds pretty much ideal. I'll keep checking in on this project.
Meantime I've just installed go... Wish me luck!
Meantime I've just installed go... Wish me luck!
The go compiler statically links it's binaries, so there are no external dependencies to worry about.
Wow, I can't believe I didn't see this before. I have been learning Go for a couple of weeks and had been searching for something like this the whole time. They should add a link to the list of libraries at the Golang site.
I see this is also from one of the Go contributors. Nice!
http://golang.org/CONTRIBUTORS
I see this is also from one of the Go contributors. Nice!
http://golang.org/CONTRIBUTORS
http://go-lang.cat-v.org/pure-go-libs has a great list of Go libs.
It's nowhere near production ready, so linking fro golang.org would be a bit premature.
I would strongly suggest to use a different command name than 'rev' since that is already a standard unix command. How about just calling it 'revel' and then people who value short names can just alias it?
Makes sense, thanks.
(I've never used the "rev" unix command before, so I didn't think much of it)
(I've never used the "rev" unix command before, so I didn't think much of it)
Being a fan of Play Framework, this could finally represent an opportunity for me to dig into Go. I regret the absence of an ORM, but will give it a 'go' (...) anyway.
PS: I regret that no performance analysis nor benchmarks are presented on the project page. It could be nice to have a comparison with Play on that domain.
PS: I regret that no performance analysis nor benchmarks are presented on the project page. It could be nice to have a comparison with Play on that domain.
I did not package an "official" ORM with Revel because I did not feel like there was a clear choice yet. (And making an ORM is too big a challenge to bite off in addition :)
I think that GORP is the current leader (https://github.com/coopernurse/gorp), and it is pretty easy to make a plugin/interceptor that initializes it and starts/ends transactions before / after requests.
I am planning on adding an example of this to the samples in the near future.
I think that GORP is the current leader (https://github.com/coopernurse/gorp), and it is pretty easy to make a plugin/interceptor that initializes it and starts/ends transactions before / after requests.
I am planning on adding an example of this to the samples in the near future.
I will have a look at gorp. Thank you for your answer.
If you need an ORM with Go you are probably _doing it wrong_.
ORMs make little sense other than to make flawed OO type systems match relational databases. Just do it right from the start: use a database model that matches your application.
ORMs make little sense other than to make flawed OO type systems match relational databases. Just do it right from the start: use a database model that matches your application.
I want to play with this, but ...
First impressions you know ... :-)
~/Dropbox/Documents/Go % bin/rev github.com/robfig/revel/samples/booking
~
~ revel! http://robfig.github.com/revel
~
~ unknown command "github.com/robfig/revel/samples/booking"
Run 'rev help' for usage.
~/Dropbox/Documents/Go % rev help
~
~ revel! http://robfig.github.com/revel
~
~ usage: rev command [arguments]
~
~ The commands are:
~
~ run run a Revel application
~ new create a skeleton Revel application
~
~ Use "rev help [command]" for more information.
First impressions you know ... :-)
Template Compilation Error (in errors/404.html:10): function "include" not defined
AGREED!
Will certainly repost when it gets a little further along.
Will certainly repost when it gets a little further along.
Ah the fix was simple: bin/rev run github.com/...
But now it fails with an error that I don't really know how to fix as a Go noob ...
Go Compilation Error (in /usr/local/Cellar/go/1.0.2/src/pkg/github.com/robfig/revel/samples/booking/app/controllers/db.go:6): import "github.com/mattn/go-sqlite3": cannot find package
But now it fails with an error that I don't really know how to fix as a Go noob ...
Go Compilation Error (in /usr/local/Cellar/go/1.0.2/src/pkg/github.com/robfig/revel/samples/booking/app/controllers/db.go:6): import "github.com/mattn/go-sqlite3": cannot find package
Ah, this is because the app uses go-sqlite3, which you haven't gotten in your local repo yet. I need to fix the command line to download all dependencies first.
You can fix it manually with:
You can fix it manually with:
go get github.com/mattn/go-sqlite3
go get github.com/robfig/revel/samples/bookingApologies -- the right command is now:
bin/rev run github.com/robfig/revel/samples/booking
I started playing around with Go on GAE just yesterday. I will probably try out a side project on Revel and see how it goes.
I have been researching other GO web frameworks last two days and this one is undeniably the best looking yet. But, I really wished they had integrated an ORM from the start. Also, I wish could know "why" they chose play framework as an architecture reference.
I am definitely looking to develop a good story for ORM. However, I don't think it has to be in the very core of the framework -- allowing people to plug a different one (or not use one at all) is important.
I chose Play! (1.x) because it is by far the most productive development environment I have ever used (especially for boring business admin pages). (Out of Django, JSP, Lift, GSE/GXP, Jetty, etc).
I chose Play! (1.x) because it is by far the most productive development environment I have ever used (especially for boring business admin pages). (Out of Django, JSP, Lift, GSE/GXP, Jetty, etc).
Gorilla and pat (by the author of Sinatra) are probably the web "frameworks" I would recommend if you want to stick with minimalist idiomatic Go style.
http://code.google.com/p/gorilla/
https://github.com/bmizerany/pat
And just say no to ORM.
Disclaimer: I contributed to the original Gorilla design, but all the credit should go to moraes (and everyone else who was contributed to the project).
http://code.google.com/p/gorilla/
https://github.com/bmizerany/pat
And just say no to ORM.
Disclaimer: I contributed to the original Gorilla design, but all the credit should go to moraes (and everyone else who was contributed to the project).
A lot of Go programmers, and I think I'd like to include myself here, are going to want to be able to plug in their own persistence backend.
For my own part, a lot of my work has some connection to a scaling problem of some kind. A mandatory/single-database-type ORM is totally out of the question and largely why I had to abandon Django for Flask in my Python work. I might at some point migrate to Pyramid for Python, but I haven't evaluated the state of their persistence story. I was mostly wooed by their testing strategy (it's drop dead sexy).
For my own part, a lot of my work has some connection to a scaling problem of some kind. A mandatory/single-database-type ORM is totally out of the question and largely why I had to abandon Django for Flask in my Python work. I might at some point migrate to Pyramid for Python, but I haven't evaluated the state of their persistence story. I was mostly wooed by their testing strategy (it's drop dead sexy).
I really wish it worked on Google App Engine. It would be cool to have abstraction layer, so there's no vendor lock-in with GAE.
Not trying to be awkward or anything, but why would you use GAE without using all the technologies that lock you in to it?
If you write a "vanilla" application which can run on GAE and other platforms without significant work, then I don't see how you'd get much benefit from GAE itself, but I might be missing something.
If you write a "vanilla" application which can run on GAE and other platforms without significant work, then I don't see how you'd get much benefit from GAE itself, but I might be missing something.
Why doesn't it?
I like the routing syntax. Enough to make me give it a try.
Just wanted to alert people that this is not ready for prime time yet. I have a sizable list of items to get through before I was planning to publicize. For example, the packaging/deployment is not there yet (working on that presently). Also, I have only tested it on OSX (in theory, it should be cross platform, but I'm sure there are bugs to smoke out).
That said, please feel free to give it a try and open issues for anything you find.