The Alagad battleship is turning. For years now we have followed more or less the same process for developing applications. Namely, we’ve made use of now-traditional ColdFusion frameworks such as Model-Glue, ColdSpring, and Reactor. We’ve played around with various alternative frameworks and techniques, but essentially, this is what we’ve done for several years now. And through those years of experience we’ve learned a few valuable lessons.
For example, I’ve learned it’s a heck of a lot easier to not manage your own requests and let Model-Glue do that. I’ve learned the beauty that is Inversion Of Control. And, sadly, I’ve learned that ColdFusion Components are really, really, heavy.
Over the least few years we’ve had a number of applications we’ve created which, to me, never felt as performant as I felt they should. Granted, tuning ColdFusion and JRun makes a big difference, but more and more we’ve had to apply techniques to work around ColdFusion’s shortcomings in this respect.
There are still aspects of ColdFusion that I really, really like. For basic applications ColdFusion components work just fine. Then there are features like the ability to integrate with, essentially, everything which are easy to take for granted. Not to mention the features that allow you do pretty much anything easily. And it helps that my team knows ColdFusion inside and out. But, for me, the component performance has slowly been whittling my will down. And, when you realize that there are teams at companies like IBM and RedHat whose entire job is to create and support open source tools that compliment Java, you really begin to realize that tooling in ColdFusion is just subpar.
Last summer I was lucky enough to see Joe Rinehart at Scotch on the Rocks talk about Groovy. For those of you who have not yet heard of Groovy, it’s a really nice dynamic language similar to ColdFusion which compiles directly into Java classes that any Java application can use, including ColdFusion. And, because you end up working with Java classes, excellent tools like Hibernate and Spring are available to you and you no longer have to pay the CFC-overhead-tax.
Since seeing this presentation I’ve read up on Groovy and I’ve played around with it a bit and feel that it’s a good, strong, contender. I honestly don’t know or have an in-depth understanding of all the language features, but I like what I’ve seen so far.
Our plan at Alagad now is to start developing the model and service layer of our applications in Groovy. We will configure them using Spring and use Hibernate for persistence. We plan to continue to use ColdSpring, Model-Glue, ColdFusion (maybe some day Railo) for the presentation tier of HTML based applications. I believe that this will ultimately give us the best-of-breed structure for Enterprise class web applications. In fact, it should be fairly simple to start using BlaseDS for Flex integration with our Spring configuration as well.
With that said, none of this is easy stuff. It’s quite different from how my team of ColdFusion developers is used to developing. At this point we really only have the vaguest idea on how to configure a development environment. There is a lot to learn. We’re lucky in that Joe Rinehart has agreed to help us learn some of the more important concepts. As Alagad moves forward on this slowly I plan to blog about lessons we’ve learned, how we setup our development environment, how we test and deploy applications, and more. So, please watch this space. Be sure to ask questions and try to steer the topics I post on. The next thing I’ll post is a general overview document Joe wrote for us.