Ruby on Rails + CDI/Weld on Torquebox example app

For almost a year we’ve been successfully using Torquebox together with CDI/Weld as a base for two of our services: JBison and Circular. As we’ll be doing some presentations together with Tomek Szymański we’ve created a small application showing our setup and the CDI<->RoR integration.

The code is available on GitHub: https://github.com/softwaremill/trqbox-demo together with a readme explaining the modules, how to run the application and how to re-create it. Hope it will be helpful.

The application consists of two main modules: the backend and the frontend.

The backend is written using Java and CDI/Weld for dependency injection and management. Here we can use the whole power of CDI, with extensions, interceptors, producers etc. Also nothing stops us from using other JEE components (e.g. EJBs, JAX-RS, servlets), as Torquebox is built on JBoss AS 6, and the deployed application behaves more or less like a .war.

The frontend, on the other hand, is done purely in Ruby on Rails (plus some Javascript). For frontend development static typing is more often an obstacle than help; also, the fact that all changes are immediately visible (no redeploying etc.) is a great gain. Moreover (at least for me) doing rich ajax apps is much easier in RoR than when using e.g. JSF.

To bind the frontend and the backend, with the help from some infrastructure we can “inject” CDI beans into Rails controllers or an arbitrary Ruby class (which runs on JRuby, same JVM), e.g.:

1
2
3
4
5
6
7
class MyController < ApplicationController    
  include_class "pl.softwaremill.demo.HelloWorld"
 
  def index
    @data = inject(HelloWorld).compute_data
  end
end

So we can easily call our business logic to obtain data that should be displayed or trigger an action. Currently this works as a service locator, but thanks to some feedback from the Poznan JUG presentation we had this week I’ve got some ideas on improving it.

Our normal cycle of development is the following: first we develop the backend, using unit tests and Arquillian (integration tests) to verify that the beans behave as they should (if, for example, there are some new entities or queries, we test them using DB test). When this is done, we can deploy our new beans and proceed with writing the frontend.

This results in pretty fast development and little time spent waiting for the AS to boot. Plus the pleasure of using something new and unconventional ;).

Many thanks to Bob McWhirter and the whole Torquebox team as well as to Ales Justin for helping to solve some MC-related problems.

Adam

  • Alex

    Adam, it would be amazing if you could post a blog comparing and contrasting Rails and JSF for frontend development.

    I’ve used both and they each have their highpoints. Rails definitely gets you started quickly and provides a lot of well thought out functionality, particularly with deployment.

    JSF’s facelets and bidirectional databinding is awesome and it’s great for forms that have a lot of conditionally rendered fields. JSF’s pull-style mvc is also great when a page draws upon multiple concerns.

  • http://www.warski.org Adam Warski

    My main pain points with JSF are:
    * it’s mostly server-side, so adding some client-side logic and manipulating the DOM e.g. using JQuery is either hard to impossible. RoR has great support for JSON and doesn’t interfere with the resulting HTML
    * it is hard to do dynamic form generation, when the exact set of controls isn’t known upfront. This really boils down to the render-time/compile-time distinction
    * custom tags are painful to write – e.g. displaying a simple recursive structure doing it “the JSF way” is a day of work

    Adam