Clojure and Rails - the Secret Sauce Behind FlightCaster (YC S09) | Hacker News Reader

Clojure and Rails - the Secret Sauce Behind FlightCaster (YC S09)

infoq.com

77 pointszemariamm19 comments

I think a lot of people could benefit from Rails as, essentially, a presentation layer for a larger system. I sort of sleepwalked into it in my own project: my Rails site is just the presentation layer for long-running Prawn-based PDF export jobs.

That could just as easily be the sort of batch processing Big Freaking Java Enterprise stuff we do at the day job -- we'd spend 1/10th the time on writing screens and action classes and still be able to use that ridiculously overpriced report generation library we're married to.

Wait a second... that needs to get brought up on Monday at work.

A spectacular combo is JRuby on Rails for the "front-end" and Scala for the heavy lifting.

interacting only through db?

If I were going to do this I would integrate input from user actions as messages using a serialization like Thrift or ProtocolBuffers and likely an AMQP transport. This allows you to hook into the system in a number of places with whatever language makes the most sense. Getting data to the presentation layer is going to be really dependent on what type of data you're dealing with so it's hard to give a pat answer to that, but in the most basic of cases, you can continue to use a messaging based approach and combine it with a distributed hashtable/cache system.

This approach allows you to hide the data models of both parts of the system from one another so you don't end up back in the hell of integrating via the database, which is what I suspect you were driving at with your question. You obviously can't avoid having to share some information between systems, but in this model you can share message and service contracts rather than database schema.

That's smells a bit of architecture astronaut to me if you don't mind me saying. Sharing information between systems is a tradeoff (vs arch complexity), not something to be avoided at all costs.

It certainly is not appropriate in every circumstance, but it can make a lot of sense for larger applications where you might have different people or even teams responsible for different parts of the application.

JRuby can call java too... We have it creating messages on a message queue.

The JVM has no shortage of message queue systems unlike other languages. Any language with the enterprise stamp on it will probably have 50 something message queue systems for it.

We're on a JVM platform as well. Since there aren't many good web frameworks for Java, Rails makes a good fit here.

what about spring mvc/webflow? I worked never on it a month back and now am ready with our Intranet portal within 3 weeks

Spring MVC is arguable as old as Rails, but I haven't seen anything come close to frameworks in the dynamic language space. There's a reason why there's such a big community behind frameworks like Django & Rails. You won't find a community this large for any of the Java web frameworks.

What about grails? It seems to me that being on the JVM would make that a very attractive choice. I'm strongly considering the grails+groovy / Scala combo for my next project. I'm just waiting for Scala 2.8 to finalize since I need it for it's full annotation support.

From my limited experience with grails, the documentation was really lacking, especially when compared to Rails and Django.

Not to mention the fact that the guy who co-invented Groovy is now a Scala advocate.

> Not to mention the fact that the guy who co-invented Groovy is now a Scala advocate.

This seems to have been turned into a giant piece of FUD against groovy which puzzles me. He didn't say anything bad about Groovy. He simply said that had Scala already existed, he would not have invented Groovy. Like saying, if I had a Lamborghini I might not bother buying a Porsche. I don't see why all of a sudden people think it means Groovy is bad any more than it means a Porsche would be bad. It also means that you'd be unhappy with JRuby or Ruby itself for that matter since all the reasons he gave for liking Scala were about it's static typing and other features Ruby doesn't have. Or of course, perhaps you just enjoy indulging in language FUD and I'm feeding a troll.

Re: documentation - I think you're probably right that Rails is better, but I think both are above the necessary threshold that it's not a problem either way.

Sorry, I certainly didn't intend to spread FUD; I was just stating my opinion which, as I mentioned, is limited.

But if a language designer tells me "hey, if item B had existed when I created item A; I wouldn't have needed to create item A", that sounds like an improvement.

I don't really care for Groovy in either direction (it's not bad but it ain't great); but I fail to see how mentioning my opinion is trolling.

He simply said that had Scala already existed...

Actually, Scala did already exist when Groovy was created. What Strachan really said is this:

"I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."

- http://macstrac.blogspot.com/2009/04/scala-as-long-term-repl...

That said, I still think Groovy and Grails are a potent combination for increasing productivity in traditional Java shops.

Here is a previous discussion on FlightCaster's architecture in case anyone missed it: http://news.ycombinator.com/item?id=772808

My question is why wouldn't someone want to use something like Compojure so they can use Clojure exclusively?

And lose all the Rails infrastructure, plugins and functionality? After all, Rails is actually a collection of technologies and perfectly usable as a presentation layer alone. And hey, once we've put Lisp on the JVM, why not Clojure on Rails?

Compojure's not really ready for prime-time yet. Try writing an app in it, you'll see what I mean ... once in a while, a baby tooth just falls out.

Reply on news.ycombinator.com