I was first introduced to the Grails framework when I first started working for Prominic, and to say I was skeptical at the start would be an understatement. This was my first time working with a web framework, and my first month or so was spent trying to figure out how to get my first basic project off the ground. Over a year later, I have a much greater understanding of how the Grails framework can be used to quickly create simple web applications, as well as support the creation of much more complex projects. To any that may be considering using Grails for future projects, I feel that an overview of my experiences with it could be helpful to those unfamiliar with it.
The Profiles in Grails
Grails as a framework has many strengths, with its profiles being the most crucial feature to starting new projects. Introduced (to my knowledge) around Grails 2.3 and expanded on in Grails 3.0, the profiles act as templates for starting common projects in Grails, based on their intended functionality.
The profiles package together a default set of plugins and generate a skeleton layout for the project. For example, the web profile (considered the default profile) on Grails 3.0 creates the controllers, services and views folders for organization of the project, whereas the REST profile strips out the majority of the plugins used by full web applications in order to facilitate a lighter weight REST application. Both of these profiles come with their own class generation scripts to generate the beginnings of controllers, views, and services to be used in the application, further cutting down the amount of ‘manual coding’ that needs to be done on well-defined class types.
Having these profiles allows a developer the to start a new project and get the very basics of it up and running with minimal effort, regardless of if this is your first or fiftieth Grails application. These profiles also speak to the variety of different applications that can be built using the Grails framework. Angular, REST, web and plugin profiles are currently supported officially, while custom made profiles provided by the community or self-made also add to a developer’s ability to get most types of web applications working with Grails.
What’s a GORM For?
After starting your application, GORM (Grails Object Relational Mapping) is built into Grails applications to make the databasing of your persistent data more accessible to those unfamiliar with the intricacies of database design. By leveraging the concept of ‘code-first databasing’ as well as Hibernate, GORM enables you to think about the persistent data in your application in a more intuitive manner for developers, as the table design is done through Grails domain classes.
Written in syntax that very closely resembles standard Java classes, GORM takes care of the complex task of creating and relating the various tables needed, while still allowing for fine control of what the underlying database will look like.
Using the data stored in your database is also simplified, allowing for querying for specific data via a set of dynamic finders, built for you by GORM based on the properties specified in your domain classes. Like other Object Relational Mapping engines, GORM makes the persistent data in any web application fit much more comfortably in a modern Object-oriented language and project design.
It’s So Groovy!
Lastly, it is near impossible to talk in depth about the strengths of Grails without talking about Groovy, the language in which Grails applications (and Grails itself) is written in. Groovy is an optionally typed, dynamic language for the Java platform, with both static typing and static compilation capabilities. This means that Groovy is well-suited both for small script-like programs or tools, as well as complex multi-level full applications.
Like other languages built for the Java platform, Groovy holds on to many of the same premises of Java and Object Oriented Programming (OOP), while cutting out as much of the largely unnecessary syntactic ‘fluff’ that Java requires. At the same time, however, if your application has a large amount of code already written in Java all of this code will still work inside of a Groovy application, along with compiled JARs or other third-party Java libraries.
As a programmer who originally came from the “C Family” of languages (C, C++, C#), Groovy feels like what I always wanted Java to feel like; a powerful, high-level language that can be concise, while still fully supporting the tenets of OOP.
There Is a Catch…
My experiences with Grails, however, have not always been positive. Due to some of the choices made while designing Grails, as well as how the community maintaining it has supported it, Grails can be rather frustrating to get started using.
One of these design decisions is that the Grails framework describes itself as ‘Convention over Configuration’, which essentially means that there is a set of rules that Grails expects its applications to follow, and that these rules are largely unchangeable. For instance, in a default Grails application, Domain classes
need to exist on a specific file path in order to be treated as a Domain class by the application. Even though the start-up scripts for Grails applications create this path for you, and it is well named, it is fairly easy to forget this and create a domain class elsewhere in the application, only to be confused when the application starts up without creating a table for this class as is expected.
Things like controllers not having a database session by default were also early stumbling blocks for me, though through experience and reading the Grails documentation very closely, most of these growing pains are easily alleviated. It has been my experience that once you learn how Grails wants you to do things, it becomes much easier and faster to accomplish your goals.
Aside from using the official documentation for Grails (found at docs.grails.org/latest/guide/single.html), there are significantly fewer resources available than there are for other languages, leading again to a more painful learning experience for beginning developers.
The solution I have found is two-fold:
- first, keep the official documentation open as it is surprisingly comprehensive;
- second, use the community’s Slack channel. For those unfamiliar, Slack is a messaging application designed to be used in a project team setting. Grails has a dedicated channel for its community, and allows open access to it for developers to ask questions and report bugs to the team developing the framework, as well as communicate with other developers that may have their experience to share.
What About an IDE?
The last problem with Grails is really no fault of the framework nor OCI, but there is currently no open-source or free IDE for Grails that fully supports Grails. Originally, there was an extension for Eclipse by the name of Groovy/Grails Tool Suite (GGTS), but around the time Pivotal more or less abandoned the Grails platform, the developers of Groovy/Grails Tool Suite stopped updating it.
This means that for versions of Grails beyond 2.4.3, GGTS really doesn’t work as a full IDE anymore. The officially supported IDE of Grails 3.0 and later (now on 3.2.3) is IntelliJ from JetBrains, which although is an excellent, full-featured IDE for many languages is rather expensive. Having an open-source or at least more affordable IDE would likely lead to greater usage of the framework, and I believe that OCI is trying to work with some community developers to have an Eclipse add-on for Grails again, or else some other open-source IDE solution.
From New to Favorite
Overall, using Grails and Groovy as a web application platform has been a very positive experience, for me. The capability to spin up web applications and focus on the more complicated aspects of the project rather than just getting it started is the strength of frameworks like Grails, while Groovy has quickly become my favorite language to write small personal tools in as well as larger projects for school or work. If you haven’t worked with it yet, you should give it a try. It just might make your work just a little easier.