Revel, high-productivity Go web framework modeled on Play Framework | Hacker News Reader

Revel, high-productivity Go web framework modeled on Play Framework

robfig.github.com

191 pointsfreeman47838 comments

Revel author here.

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.

Can you add a license to the git repo? You mention MIT on the webpage, but no LICENSE file or license headers show up inside the project itself.

Done

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.

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)

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

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.

And, he uses "go build" to build the program:

    out, err := exec.Command("go", "build", "-o", "prox.exe", rootPackage).CombinedOutput()

It appears to do more than Revel does, though -- I will look at it more closely to see what extra it provides. Wish I had seen this before!

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.

awesome!

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:

    >> If the app compiled successfully, it runs the app ...<snip>...

Is it simply a case of lifting and dropping the binary (ensuring it's linker dependencies are satisfied on the dest host)?

Would the final artifact be deployable to google app engine?

The go compiler statically links it's binaries, so there are no external dependencies to worry about.

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.

Your direction sounds pretty much ideal. I'll keep checking in on this project.

Meantime I've just installed go... Wish me luck!

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

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)

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.

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 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.

I want to play with this, but ...

  ~/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.

It would be nice if the 'quick start' would just work.

First impressions you know ... :-)

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

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:

    go get github.com/mattn/go-sqlite3

Also, I believe that the go command line figures out the dependencies for you, so this should get everything you need:

    go get github.com/robfig/revel/samples/booking

Apologies -- the right command is now:

    bin/rev run github.com/robfig/revel/samples/booking

Changed in last two commits and I was a laggard in updating the site. Updating now, thanks.

  Template Compilation Error (in errors/404.html:10): function "include" not defined

Hey Rob, how about reposting this when things are in better shape? I've been waiting for a good excuse to play with Go and your web framework looks like something I could use for some real experiments, but it needs to be a little more finished first I think.

AGREED!

Will certainly repost when it gets a little further along.

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).

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).

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).

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.

Why doesn't it?

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.

I like the routing syntax. Enough to make me give it a try.

Reply on news.ycombinator.com