«Truth can only be found in one place: the code.»
30 Jan 2016 | grails, architecture
I’ve just worked in a project where we upgraded a web application from grails 2.x to 3.x. One part of the application was divided into a plugin and three slim grails applications, which kinda inherited from this plugin. One of the grails applications was the official end user application and the other two where some kind of preview applications. We had some issues with this structure because plugins have the following disadvantage while development:
| Grails | Application | Plugin |
|---|---|---|
| enable/disable Javascript/CSS uglify/minify through asset-pipeline | ![]() |
![]() |
| do not pack all Javascript/CSS files into one (debugging in browser) | ![]() |
![]() |
| hot swapping / reload after file changes | ![]() |
![]() |
| debugging in IDE (Intellij Idea) | ![]() |
![]() |
| recompile TypeScript after file changes | ![]() |
![]() |
We definitely needed hot swapping and separated JavaScript files while development. The solution was to make out of the plugin also a fully executable grails application.
I saw the blog of Klaus Lehner and his conclusions of grails in bigger projects. In his article he says that you can’t really modularize grails applications. With my experience of extending grails plugins to grails applications, I’ve developed an prove of concept in an modularized web application with a frontend and backend and a common module for both of them. My use-case looks as following:

In order to have full comfort in development, as described above, the common, front and backend are grails plugins and grails applications. You are able to run each one. The main application bundles front and backend to one application. You can find the code on github. I used the layout example from mrhaki and split it into the three modules.