Hacker News Reader

Comment by playing_colours | Hacker News Reader

Does it make sense to try using both Clojure and Rails in web app, Rails for UI and Clojure for more sophisticated business logic?

View on HN

This is actually a fairly common choice for startups, the "deployment mullet". Business up front, party on the back end.

It should interact pretty well with JRuby on Rails, but I'm not sure you would get any benefit from using rails over a Clojure web framework like Noir.

I had a look at it but it's pretty young. I would prefer more mature framework.

Look at torquebox.org and immutant.org. You can run ruby and clojure on the same JVM and they can interop in a few ways.

It's possible to get quit a lot accomplished by loosely coupling Ring+Compojure, Enlive/Hiccup, and datastore modules like Clutch, Korma, clj-orient, etc.

I began my journey into Clojure about a month ago (after poking at it since last Sept) by diving into the "Clojure Programming" book recently published by O'Reilly. After finishing the book, I reached for Noir to fill my web-dev needs, as the idea of a "batteries included" framework appealed to me. But I ended up dropping Noir and adopting the approach explained in the book, i.e. loosely coupling the modules mentioned above.

Noir itself is built from some of those same modules, and it seems like a fine open source project, but I've found that I'm better off connecting the "lego blocks" together manually -- it's not a complex exercise and gives you a lot of freedom to experiment, learn and fine tune.

I've used Rails and Noir and they're not really comparable. Noir is much more minimalist and doesn't cover nearly the same ground as Rails. Noir is more like Sinatra as I understand it.

The Clojure mentality so far has eschewed all encompassing frameworks like Rails in favor of smaller interfitting libraries anyway.

I honestly think you should avoid this. We did this, and it's a nightmare, and we had to get rid of it.

Rails works very well if you stick to defaults. Each time you veer a little bit further from the defaults, things start to break (or at least require a lot more advanced knowledge to keep working).

We had a front-end in in JRuby-on-Rails, backend in clojure, in the same app/process. We had a "middle-end" which translated clojure->ruby and ruby->clojure, allowing us principally to use futures for parallelism and queuing. It worked really well at the start, but had tons of bugs. A nasty example was that we did email in SimpleMailer in Rails, but it was triggered from some backend functions, which in turn were triggered from the front-end. That meant that Ruby objects were being used in two different Ruby runtimes! Bugalicious.

Here's the library we extracted, if you really want to use this: https://github.com/circleci/cljr. My cofounder Allen talked about the experience at ClojureConj/west: https://github.com/arohner/clojurewest2012-slides/blob/maste...

Thanks for the correction, good to know. In the example you describe, the main mismatch seems to have been getting the two Ruby runtimes to communicate effectively. Was that a common theme?

I think the most important thing is "complexity is multiplicative". Every slight deviation from normal led to subtle errors that took days to fix, and kept coming back in different ways. The runtimes was just the most WTF way this happened.

There is actually another talk from Clojure/West on this topic that will be posted later on...

I would say yes if you build the Clojure component as a separate service that the Rails app makes calls to. Or I guess you could simply build it as a Java class and use Rails to execute it.

Yeah I am interested in the scenario with using Clojure-written web services.

Definitely. See my comment above about why not to do it in a single process.

this is what twitter is doing with scala i believe.

Reply on news.ycombinator.com