As architect within a group for a health care concern that was still employing STRUTS 1 I had looked into a few offerings available. SEAM was of interest as it leveraged JEE standards and we were primarily a JEE shop. Grails was looked into but it seemed too much of a stretch for us. Then I switched jobs and entered an academic setting. This group was a littler further ahead in the Java curve and had been employing Spring for several years. Of course some would argue and say JEE is standard and a good place to be. I'm not going to argue that here. I will just say that many architectural concepts, inversion of control, dependency injection, AOP, POJOs for ORM, and more espoused by Spring for some time, have been introduced in later versions of JEE.
SO being a group that was primarily focused on Spring MVC/Hibernate web application development Grails was much less of a stretch. Having said that it may have made our decision somewhat easier to make but I would STRONGLY encourage JEE shops and .NET shops and shops of any kind to transition to Grails - IF - you are primarily doing web application development. And today that would be most of you out there doing any kind of application development. And whether its enterprise applications, departmental, or even mobile you would find that Grails has a LOT to offer. And if you research Grails current roadmaps you will find that they are moving to an EXTREMELY flexible architecture based on their plugin architecture (more on that later) to enable you to basically customise the stack to fit the type of development you are doing.
So what are we so happy about? Well I think most of us would tell you that we can get development done anywhere from 20 to 50% faster. How is that possible? Here's a few of the reasons:
- Grails - the web framework
- Plugin architecture
- Groovy (yes its all groovy but this is referring to the language used)
Grails - the web framework
COC Convention over configuration
Grails heavily leverages COC. And why not! By laying out a very elegant manner to do the things you would do anyway but without configuration and boilerplate code you can quickly create a functional application that accomplishes a lot.
How quickly? Well minutes much of the time. Is that to say you will create full web applications in minutes? No - because everyone has specific requirements,. But as a developer what does it mean to you to get something up and running quickly that can then be tested and iterated to completion? The sooner something is actually functioning the more productive your coding will be The sooner clients can be engaged in the process of looking at something that is running and offering feedback which will greatly improve client satisfaction and time to delivery.
And after delivery? We all know that development is 20% and maintenance 80% and sometimes it can be even more skewed if the application is long lived and changing frequently. Having a LOT less code to wade through is HUGE.
Streamlined application architecture
One of the issues we have in our new group is that we have one side of the house that tends to develop with LAMP. Although LAMP often falls to the wayside when technologies are needed like XML frameworks to make things somewhat easier and then Java comes to the rescue. These applications are created with things like PERL, PHP and low level Java technologies (Cocoon). A subject that keeps coming up on that side of the house is who will back up a developer for those applications if the primary is out of the office. So much time and energy must be set aside to learn what another developer has done.
On the Grails side we have no such issue. Anyone of us feels very confident that they can jump into any Grails application and ramp up very quickly. Why is that? Several reasons including COC (discussed previously), the Groovy language (discussed later) but largely because Grails prescribes a very simple and elegant architecture. What does this mean for the developer?
Well, first off, no more spending time acquainting yourself with the architecture of the application. Even with a framework such as Spring MVC there are myriad ways to configure things for views and templates (eg. tiles) not to even mention the back end code which may employ different styles of persistence APIs (JPA, Hibernate), different stereotypes employed (DAO, Repository), and different configuration means (XML v. annotations). When a developer looks at a Grails application he will already be intimately familiar with the structure, where to find configuration for both runtime and build time, datasource connectivity information , and be instantly familiar with the requests available in the application via the controllers. Spring MVC and other frameworks have controller concepts but I would dare state that the Grails version is more elegant. I for one find many of the concepts in Spring MVC kind of clunky - like building parts of your model in separate methods that get invoked by the framework for a request. When you look at a Grails controller method/action its all there for you to see what is done for the request. Of course there are other facilities that you can use such as filters and URL mappings and more that may add complexity but here again Grails simplifies by having a well defined project structure. You know EXACTLY where to find all of these.
Ecosystem
We all know what ecosystems are and these days with social media anything can create an ecosystem. But is it crazy to say that the Grails architecture lends itself to fostering an ecosystem? No it isn't - and there is one BIG reason for that - the plugin architecture. That will be discussed next. But here I want to mention that large pool of developer talent out there hard at work providing pluggable pieces to the Grails framework. And here is a very great example. At a recent conference, SPRINGONE 2GX ( which gave me the motivation to create this blog) , my second year in attendance, one presentation was from a developer from France. What this developer had done was to write a plugin that performed scaffolding for Grails that employed the JQuery mobile Javascript framework for the UI. He demoed the creation of a fully functional HTML5 based MOBILE web application using JQuery mobile and Grails in 5 MINUTES! And the plugin sits there lying waiting for you to use it.You could enable a mobile interface to existing applications in no time with this plugin!
Plugin Architecture
I'm not going to get into all the technicals of the plugin architecture as I've already said this is about the value proposition of Grails as your development stack for web development - not a technical how-to. What I am going to do is talk about what it meant for us as developers trying to get work done and give a few examples of how we have used it. One thing to mention is that when you use Grails you use plugins. Grails is itself composed of plugins and this will only intensify according to their roadmap. They want to create a more flexible architecture by allowing developers to snap together via plugins what is essential for the development they are doing.
Our early use of plugins comprised of getting the shell of a web application such that someone could create a new web application and not worry about things like security, default layouts, default CSS, and default configurations. Developers within our group had made a stab at this with Spring MVC which by itself comes with no such facilities. So the idea was to use ANT to assist in templating and script the copying of resources into other projects. This type of approach caused more issues than it solved. Each project had to maintain lists of files that should not be sourced by that project and scripts had to be executed to actually create usable configuration files often conflicting with IDEs being used. The idea to enable developers to stop recreating the wheel each time they created another web application was good but unfortunately our development stack gave us NO good way to do this.
Along came Grails. Early on we decided to go ahead and create a plugin that would provide all of the things mentioned previously. The beauty of a plugin is that it is listed as a dependency and all of the folding in of the plugin is done by the Grails plugin system AUTOMAGICALLY. The following is as technical as I will get - Here is a list of all the artifacts a plugin can provide:
- ALMOST EVERYTHING!
Honestly, what it cannot is hardly worth dwelling on. In our case this one plugin provided all the dependencies we needed for DBMS use (Oracle), security (ALL Spring security default configuration and dependencies, a default layout, default CSS, LOG4J configuration, and more). Once we had created this plugin, creating a new app was as simple as running the Grails create-app command, listing the plugin as a dependency and setting a few appplication specific configurations (ie. application name, default URL for security redirection) and voila - working application shell done. This could be accomplished in about 5 minutes and then you were ready to start implementing the actual BUSINESS LAYER. You know - that part the client actually wants.
Our next use of plugins came in the form of customizations of third party plugins. For example there is a mail plugin that provides very good and very easy to use email functionality. So one plugin we created was to add a service layer to the email plugin that logged the emails sent and provided a console view that displayed the emails sent. Once done all our apps could use this plugin which in turn automatically provided the third party email plugin but with the added enterprise functionality. When have you ever been able to create shared functionality that included views that could be injected into your application as easily as adding one line of configuration for the dependency?
The former uses of plugins involved us creating our own either from scratch our by adding functionality to other existing plugins. But for the most part you will simply use third party plugins as is. And it bears examining some of our uses of these third party plugins.
I already mentioned the email plugin. And some of you might be thinking - big deal - Java has APIs for emailing. Yes it does but you have to understand the order of magnitude difference between using a plugin and an API. One thing a plugin does is provide functionality on top of an API. And many of the plugins do just that. They take a JAVA API and customize it with new functionality that renders it much more useful.
In the case of the mail API it did a few things to make sending emails so much more simple. One, it created what is knows as a DSL for the creation of an email. I won't get into DSLs here except to say they are mini languages (Domain Specific Language) that give a greater level of expressiveness to your code for a specific problem (domain). The email plugin also added the clever capability to provide an override address capability that you can use in test to ensure that all emails go to one or more addresses only. Have you ever known of anyone that had the unfortunate event of sending emails to actual people in testing. I've heard of developers that accidentally sent hundreds of emails out.
In the case of the mail API it did a few things to make sending emails so much more simple. One, it created what is knows as a DSL for the creation of an email. I won't get into DSLs here except to say they are mini languages (Domain Specific Language) that give a greater level of expressiveness to your code for a specific problem (domain). The email plugin also added the clever capability to provide an override address capability that you can use in test to ensure that all emails go to one or more addresses only. Have you ever known of anyone that had the unfortunate event of sending emails to actual people in testing. I've heard of developers that accidentally sent hundreds of emails out.
Another thing plugins do versus APIs is to adapt that API very carefully to an architecture. Another plugin we have used is a great example of this - the render plugin. One of the render plugins central features is the creation of PDFs from your html views. The core API providing this functionality is Flying Saucer which some of you may have heard of. In turn, flying saucer utilises iText which many more of you have probably heard of. What flying saucer adds to iText is the capability of parsing an XHTML file and using iText to render the equivalent of the XHTML as a PDF. Fantastic functionality that allows you to reuse your web views for PDF creation or to leverage your HTML/CSS skills to create original PDFs. In the case of the render plugin, flying saucer was adapted so integrally to Grails that the plugin adds dynamic methods to Grails controllers (something many plugins do) which were similar to the existing common Grails method to render standard GSP views. The plugin dynamically adds a renderPDF method that can be used for returning a PDF instead of the usual type of Grails view - a GSP. This method takes exactly the same arguments as the standard Grails render method.
This plugin section is longer than the other sections and for good reason. The plugin architecture that Grails provides is its single most attractive and most POWERFUL feature. Without it Grails would still do a lot of things much better than other frameworks but with plugins the ability to truly share not just code but true functional add-ons is very empowering to the developer.
Groovy
Lastly, but certainly not leastly ;), there is the Groovy language that Grails employs. There is a lot to be said about the fact that you have a language with modern language features that is dynamic but oddly enough the first thing I would trumpet about Groovy is that it is JAVA! I don't write that to be confusing - and yes it is factually incorrect to say Groovy is Java but one could say Java is Groovy! That is to say, loosely speaking, that Groovy is a superset of Java. Almost all Java syntax is 100% valid in Groovy. Groovy compiles to bytecode and Groovy (and as such Grails) runs in the Java VM. It doesn't really belong in this section but its worth mentioning that Grails packages into standard Java Web Archive file (WAR). For Java developers coding in Groovy can be incremental. Initially you might find yourself coding in a very Java like manner but most will quickly move on to the more compact and simpler Groovy syntax styles.
Having said that if you are not coming form a Java background it is not to say you shouldn't bother with something like Grails. After all, the fact that it sits atop a bulletproof enterprise stack like Java is a good thing for anyone. Groovy has the characteristics of many modern languages and shouldn't prove all that difficult for any developer to learn.
I would love to expound on the modern features of the language like closures but that would venture into the technical how-to and that is not what this blog is about. What I will say is that with Groovy my code is SO MUCH MORE TERSE, MORE MAINTAINABLE, MORE READABLE that its well - crazy!
Summary
I hope that this blog entry as well as others I've written about my experiences with Grails in the last 2 years are of aid to anyone interested in the framework. Feel free to contact me with any specific questions and I'll do my best to reply.
