Why Grails Is Important

Reusable components are the Holy Grail of software development—pun intended. The promise of rapidly creating reliable software from shared, reusable components has been the quest of software development companies and countless open-source initiatives since the early ’70s, resulting in the genesis of a wide range of productivity technologies and frameworks. They all promised reduced development time, improved functionality, improved reliability and the ability to let the programmer focus on application business logic. And, for the most part, they did some of these things. But they didn’t really solve the problem, did they? Development time didn’t really shrink that much.  True, the applications are more powerful and complex, but in the end, programmers are still recreating their logic, redesigning their user interface and implementing the same schema designs over and over again. Why? Why do so many technologies briefly capture the attention as the next big thing only to fade away within the decade?

The answer is simple. The problem is very, very hard. There have been three fundamental shifts in the landscape: mainframe → client / server → web, with a fourth well underway to smartphone / tablet applications. Every time an ecosystem for software reuse got started, the entire technology base was replaced virtually overnight, requiring the development of new productivity solutions and a new generation of programmers. Most attempts are restricted to narrow sections of the problem like data persistence, user interface or business logic.  It is almost impossible, even for truly excellent programmers, to keep up with the bewildering array of frameworks, architectures, and solutions that are available. Just look at what is available from Apache, Google, Microsoft and Oracle alone. It’s a 30 day research project just to learn the names of all the products much less how they work in detail.

Finally, the landscape is starting to change. Through the late ’90s and early 2000s, the industry paid the price to settle on a couple of base technologies: .Net and Java/JEE. While there is an amazing clutter on top of both, the base technology platforms are very mature and reliable.  Through the late 2000s and early 2010s we have developed a number of “frameworks” that attack reuse for core application facilities: data persistence, transactions, user interface, logging, clustering and security.  All are difficult problems and a few solutions in each space have risen to the top and survived to become mature, reliable, and performant enough to be used in critical applications. The stage has been set.

Enter the extensible application ecosystem. Several efforts seem to have originated roughly at the same time, but the thinking really changed with Ruby on Rails. It was designed from the ground up to provide a holistic environment for software development where the core application facilities were all provided.  Rather than dealing with an operating system and a programming language, you were dealing with an application environment. All the facilities were just there. You just had to reference them to use them. But … alas … Rails was developed in the Ruby language, and, while beautiful, it doesn’t have a large base of trained programmers nor a large pool of community developed open source like that available for Java. The concepts however are undeniably powerful and it wasn’t long before a similar effort based on the more mature Java platform was initiated.  Able to leverage the proven and well understood Spring Framework, Hibernate and Java servlet components, Grails provides the amazingly convenient and powerful functionality of Rails in the familiar Java platform.

Here are some of the reasons why Grails is so important:

1. Formal managed component reuse. Grails provides a plugin facility that allows virtually any part of it to be replaced, overridden or extended.  In practice, much of the functionality of the Grails platform is provided in the form of plugins. Even more important, the plugin facility is exposed to application developers so that they can manage their own set of plugins. You can mix and match your plugins with official Grails plugins or third party plugins provided and maintained by the Grails open source community. Most importantly, in a Grails ecosystem, the value of a programmer is the collection of mature, functional plugins they can bring to the table. Plugins developed to bring specialized business logic, user interface and knowledge are now available to any application to which they apply. Functionality like reporting, messaging, planning, scheduling, analytics, contact management, enrolment, payment processing, retail shopping can all be abstracted and used in any number of applications. Programmers are limited only by their ability to conceive of and abstract their ideas.
2. Use of proven abstraction architectures like Model/View/Controller (MVC) and Object Relation Mapping (ORM).
3. Support for mature and emerging technologies.  Grails even supports a number of competing technologies so that those with religion can keep their various gods happy. If you have a preference for a particular RDBMS or data representation, you can likely find support for it in Grails.
4. Grails is designed to survive changes in technology climate.  If a new technology becomes hot, it is simply wrapped into a Grails plugin and made available. If we decide that we like REST APIs better than SOAP APIs then we just add them in.  Grails supports multiple protocols and underlying technologies.

Many developers have taken the extensible application approach to building software, but few have gone so far as to build their own ecosystem. Stay tuned for next week’s blog, which will uncover how we built one of our own, and what the implications are for customers and the industry.