Grails at LinkedIn
Back in late summer of 2007, we saw a business opportunity to build a LinkedIn web application on-top of our extensive database, and we needed to build one fast (3-4 months)! We started with an extremely small team of engineers (2-3) and eventually grew to 6 engineers. We needed a framework that could give us the productivity we needed, while allowing us to leverage the extensive assets we have invested in our backend logic built on top of Java and Spring. Given that most of us are Java engineers, we wanted something that had a shorter learning curve.
I’d been playing with Grails since 0.1 days, and I thought this would be a perfect opportunity to test drive this technology. I wanted to see if we could quickly realize the productivity gains in a real world scenario. My main worries were: scalability and compatibility with the LinkedIn technology and process ecosystem. Due to the fact that this is not a free product, our initial customer base has been small and will remain small for a quite some time. Because of this, we were able to de-prioritize the usual stringent scalability requirement to allow us to give this young framework a chance to prove itself.
Another engineer (who had no prior experience with Grails) and I built two initial prototypes: one based on AppFuse 2.0 M5 (Spring MVC/JSP + Hibernate), and one based on Grails 0.6. We found that Grails was a lot faster to work with, even in its immature state. We then took a month to firm up the prototype and presented to management to gain their blessings to do it for real.
Below is a presentation that my colleagues Alex Vauthey, Borislav Roussev, Jamie Still and I put together for a JavaOne Groovy/Grails Meetup. This presentation tells about our experience using Grails to build our application.
| ViewThis is the first in a series of Grails at LinkedIn blog posts we’ll be writing. We hope you return next week to learn more about how we introduced Grails into our Ant build process, how we’re developing new Grails projects and what we like/dislike about Grails.
trackback
http://blog.linkedin.com/2008/06/11/grails-at-linkedin/trackback/
Lars Fischer June 12th, 2008
Never used Grails but does it require you to know Hibernate syntax?
Brian Guan June 12th, 2008
Hi Lars,
Grails shields you from dealing with Hibernate directly, while providing you the flexibility to bypass the ease-of-use layer to directly calls hibernate API, map POJO/POGO to tables/views/stored-procs, and/or issues HQL if necessary.
However, some conceptual knowledge of Hibernate or other ORM tools, and appreciation of their strengths and weaknesses would help with using it appropriately.
I personally find GORM (Grails’ ease-of-use layer on top of Hibernate) very easy to work with and flexible enough for our current needs, but I look forward to seeing GORM being decoupled as a standalone module so I can use it outside of webapps (like in a backend service), and also use it to talk to more than 1 DB at a time (current limitation). See Grails roadmap for 1.1: http://grails.org/Roadmap
Apart from programmatic and conceptual point of view, the configuration is also easier, but I suspect most serious usage would require more fine tuning of the various hibernate knobs and levers e.g. caching, connection pooling.
Reginaldo Delfino June 12th, 2008
The slides have been removed from slideshare, :(
Shawn Hartsock June 12th, 2008
Brian,
GORM is definitely the biggest win in Grails right now. I spent a little over a year using JPA before I discovered GORM and I think it’s the strongest point of Grails.
But then, Grails has many strong points. Not the least of which is the TagLib _authoring_ facilities.
Probably the _hardest_ thing for me to use right now is the WebFlow. Have you used this yet? I’d love to read your insights if you have any.
Brian Guan June 12th, 2008
Hi Shawn,
Yes, I like GORM a lot. Having worked with Hibernate and Toplink and raw JDBC, GORM is refreshing. Even my most esteemed colleague with PhD in CS – Srinivas Yellamraju (http://www.linkedin.com/in/yellamrajusrinivas) who is suspicious of all things magical and fashionable (he is still using Emacs!) – pronounced that GORM is clean. BTW, Y.V. learned Grails and Groovy by just glancing at my code in 1 afternoon, winces, and then proceed to build one of the most challenging module on the project. He still thinks that Groovy is “not quite LISP.”
We do like other parts of Grails – simplified Spring MVC, command objects, GSP, taglibs – all made life so much easier.
As for Webflow, we tried it back in Grails 0.6 (over 6 months ago), it was having problem working with Command objects, we logged a few bugs and rewrote the use case in our app that would have been a perfect candidate – it has a 4 form flow with multiple entry and exit points – we eventually wrote it controller logic using model state and conditionals. Not sexy, but it works.
It would be interesting to hear others’ experience on using WebFlow. IMHO it is still a little too magical – so when things go wrong, hard to troubleshoot. This is not a critique of Grails per se, but Spring Webflow itself. 2 years ago on another project, I tried raw Spring WebFlow and my feeling was the same – so I am on the fence with this one.
Jason Swartz June 13th, 2008
Hi, it looks like the slideshow was taken down or made private, can you reinstate it? I’d like to check it out. Thanks!
David Paquet June 16th, 2008
Hmm, the slideshow don’t seem to be available anymore :(
Doyle June 16th, 2008
Shawn -
Webflow is wicked easy. I use it on my live production site. (I can’t mention it in open form but you can email for the addy or for a more complete code set.) I spent about two hours figuring it out. I sorta had to change my idea of request response since it’s just a state-machine. I had a few gotchas with the gsp’s. Since there is a flow state. So I did something like this to help men out:
(copy and paste bad in this little box)
Now controlling those actions in the flow is cool. Since it’s just a controller.
So here in one controller it’s for a registration page that someone has already registered: (some names have been changed to protect the innocent)
//register user
registeruser {
render (view:”userreg”)
on(”continue”){
def userreg = new User(params)
flow.user = userreg
if(userreg.hasErrors() || !userreg.validate()){
//FieldError – Spring Class
def emailReg = userreg.errors.getFieldError(”emailAddress”)
if(emailReg != null){
//flow.alreadyReg = “Yo Login here to continue!”
}
return error()
}
userreg.save()
}.to “makeGas”
on (”alreadyauser”){
flow.flaction = “fooaction”
flow.actbutton =”userlogin”
}.to “userlogin”
on(Exception).to “handleError”
}
Then in another controller reusing the same view:
startComplete {
action {
flow.flaction = “estimatecomplete”
flow.actbutton =”userlogin”
}
on(”success”).to “userlogin”
}
userlogin{
render(view:”/user/login”)
on(”userlogin”){
def userdef = User.findByEmailAddress( params.email )
def vshop = FOOShop.findByEmailAddress(params.email)
println (”vshop email>>>” + vshop)
if(userdef && vshop) {
if(userdef.password == params.password && userdef.emailAddress == vshop.emailAddress) {
session.user = userdef
flow.shop = vshop
}else {
flow.message = “Incorrect password for ${params.email}”
return error()
}
}else {
flow.message = “User not found for login ${params.email} or you are not a Verified Shop”
return error()
}
flow.user = userdef
flow.verShopId = vshop.id
}.to “completedEstimate”
//Become a FOO shop
on(”backtoreg”){
}.to “apply”
on(Exception).to “handleError”
}
The cool thing with webflow on spring is you can really get a lot of reuse out of existing views and domains. And they are not exposed. The url for the flow is sorta of annoying but you could jam that into a cookie if you really wanted to. (It screws up my analytics) but it’s a catch 22 with that sort a thing.
On a side note do use the compress plugin very nice filter. Try it out with the yslow plugin.
I may have rambled but I really like this stuff.
-Doyle
Shawn Hartsock June 18th, 2008
@Doyle
Thanks for the example. I think you’re right about needing to think differently with the webFlow. I think what trips up most folks on the lists… myself included… is we keep trying to treat the flow like a bunch of controller closures that happen to be chained together not as a state-machine. I’ll definitely want to check out what you’ve done.
Raja Periyasamy June 30th, 2008
Brian,
I’m doing research whether Grails is a good fit for our new enterprise application. From your experience, do you think Grails is ready for enterprise application that has large volume of data transactions and many concurrent users?
Thanks.