|
|
WhyRails
Why choose Rails as the platform for Jangle?
Ruby on Rails is an agile framework for web development. Find out more about it at the Rails homepage.
There are some good reasons for choosing Rails for Jangle, at least for early iterations:
- Easy for developers to pick up our codebase: consistent code layout, attractiveness and familiarity of Rails, simplicity of Ruby
- Rapid development of prototypes (with Ruby being a dynamic language)
- Ease of deployment for end users and "drive by" developers
- Can download and use a Rails application very easily as web server is built-in and Rails has support for file-based SQLite databases - no need to install anything. If using JRuby, could potentially use Jetty and Derby to run without having to install anything. Another alternative might be KirbyBase, a pure Ruby database layer (though the project looks a bit moribund).
- Potentially could be made one click and given an "installer" using technologies like Joyent Slingshot.
- Integration tools easier to write using ActiveRecord
- For importing data from an external ILS into the Jangle schema, can use ActiveRecord model classes; alternatively, export to YAML and import using ActiveRecord
- Potential integration with existing Java code via JRuby using the JRuby Rails integration libraries
- Rails could be used as the front-end technology, with adapters being written in Ruby, Java, perhaps even Jython
- Jangle could be deployed using Ruby and Mongrel, or directly deployed into a JEE servlet container as a war
- Java developers could use Jangle as a REST layer directly inside a Java application, as Jangle could be packaged by JRuby into a jar and used like any other Java library (potentially)
- Existing Rails plugin architecture gives a base to start building connectors - perhaps a connector could be added in as an plugin
- Fewer issues with proprietary libraries: most important Rails and Ruby libraries are distributed under very liberal MIT licences
Why not Rails?
There are also good reasons not to use Rails:
- It is difficult to deploy on cheap hosting. To get good performance out of Rails, you need your own hardware, a virtual server, or some hosting. Contrast this with PHP, which you can run on dirt-cheap hosting to serve thousands of requests per day.
- Dynamic languages are still considered dodgy in some enterprise contexts, but this is changing.
- There are limitations to its flexibility. We should be mindful of the fact that we are trying to write a framework inside a framework, which sometimes makes things harder than they should be. As an example, specifying multiple database configurations inside a single Rails application is not simple, as this is starting to go outside of ideal Rails use cases (i.e. greenfield development of a web application for accessing a single database).
Sign in to add a comment
So the library support is good enough for JRuby for rest orm etc?
Yes - the whole of Rails is accessible under JRuby, including an ORM layer (ActiveRecord?) and a framework for REST; plus, if that's not good enough for you, you can call out to Java libraries like Hibernate
How real are the long term performance worries about Rails? Are a lot of the problems caused by bad practice a. la. Java strings 4 years ago? How much is caused by Ruby being a relative newcomer, there appears to be a high output of GC patches for example.
Wouldnt it be usefull to get to do a load test comparison before we get too far commited?
I think there are performance issues, still. But there is a fair amount you can do in terms of the app. server, load balancing, db clustering, caching etc. (see Twitter, for example). And the latest JRuby is much, much better than the last version.
I also think we should bear in mind that this isn't necessarily the last time we talk about appropriate development environments. At the moment, we want something which works, fast; and something nice for developers to work with. Whether it scales to millions of requests is a separate issue, in some respects. Also, there is always the option to hand off heavy-duty stuff to a Java service layer: I have prototyped this, with Jangle (in Rails) talking to a TalisSOA layer (in Java). In this instance, Jangle is just a thin layer over the Java services, effectively replacing the TalisSOA servlet.
What is the advantage of having Rails as the front end web service over the Java front end? The REST services can be defined in XML configuration, requiring no understanding of Java. Furthermore modules could be developed in the language/script of choice and called by a generic scripting engine in Java 6.
In other words why have JRuby call Java when we can have Java call multiple scripting lanugages of the developers choice, including JRuby?
Good points. I suppose our choice was motivated by several main factors: wanting something we could work with quickly, wanting to use something we are familiar with and comfortable with, and wanting to use something attractive to casual developers.
Rails gives you lots of good stuff for nothing: for example, helpers for HTML generation, easy ORM which requires little configuration, REST for free, built-in test framework, plugin architecture. Also you can still use the Java scripting language integration if you want (JRuby calls Java calls other language): convoluted but feasible. On the down side, Rails is less flexible than a custom Java architecture (though Ruby itself is at least as flexible).
We thought it would be easier to try out ideas using Rails than it would with Java. For example, over the last four weeks, we've done the following:
- Tied TalisSOA Java classes into Jangle. - Added an HTML forms front-end to TalisSOA (similar to the Talis Platform HTML interface). - Provided a means of having multiple REST interfaces served and managed from the same container. - Created a tiny ILS (the Jangle demonstrator) with a means of importing data into it. - Created HTML and REST front-ends for borrower data in Koha (an open source ILS), for reads and writes. - Provided read-only borrower data from both the Jangle demonstrator and Koha in XML, HTML, RDF and NCIP response formats.
Many of these things are experimental, but we felt we needed to do them to be able to understand the functionality which might be required from this kind of architecture, and to get discussions like this started. I don't know whether I could have bolted these things onto TalisSOA as quickly, without some major architectural work.
I think we should also bear in mind Frederic Brooks' point (I think it was him): "Plan to throw one away". It might be that Rails is the wrong platform for Jangle. But it enables us to throw ideas around and implement them far more quickly than we could in Java.
While TalisSOA has an excellent architecture and works brilliantly for Talis use cases, my personal feeling was that by the time we'd reworked it to make it generic enough for Jangle use cases, we could have written something else from scratch. Which I think we have, while still retaining access to TalisSOA. Though I still have reservations about Rails: I think Ruby is right, but Rails gets in the way a bit too much sometimes.
I think the Brooks commment is pertinent. if it turns out that rails is the wrong piece, we change it.
The hard bit is agreeing international domain models, and coding adapters - anything that helps those things happen more easily or quickly is worth doing.