Issue 62  30th December 2016

Grails 3 book - Step by Step

Written by @colaru, another Grails Book 3 is coming together. The book is a work in progress but promises to guide the reader through a Grails multi project build which combines the web, angular, rest and microservice profiles.

The only think I don't like is that the recommended price in LeanPub is way too low. A book cannot be three dollars.

I don't like Hibernate (and Grails)

Probably anyone using GORM with Hibernate should read these posts. A long series Part 1, Part 2, Part 3, Part 4, Part 5, Part 6 by Robert Peszek describing issues around Grails / GORM / Hibernate.

All of the GORM problems listed in this series can be attributed in some way to Hibernate session/1st level cache

Summarized by probably the best quote ever:

Beast sitting on a beast sitting on a beast. This stuff is complex.

In his Part 8 post he summarizes when you may encounter theses issues as your project progresses.

If you are looking for a wrap-up check Part 10 and Part 11

Grails in large scale projects | Catalysts

A series of blog posts by @klu2; Part 1, Part 2 and Part 3.

With devastating conclusions:

To put it short after using Grails for 3 years now: We wouldn’t use it for bigger projects any more.

His biggest beefs are:

Modularizaton

Modularization means me for:

• Separate backend from frontend; also having the possibility to start the application without the frontend
• Separate business modules from each other
• Reuse controllers for different output formats (e.g. HTML and JSON)

I think the use of Gradle in Grails 3, Grails 3 profiles and the Grails 3 plugins solves the modularization problems previously mentioned.

GORM Everywhere

If it is possible to write GORM code anywhere, then it will be written anywhere. In services, in controllers, in taglibs, even in gsps. Inside a transaction, outside a transaction, everywhere.

Note: this is not just a Grails thing. Normally frameworks do not restrict access to data layer. If you code in iOS you can call CoreData persistence from your ViewControllers or Views. I think It is up to every developer team to create a convention to organize code which manages persistence. For example, We have been encapsulating GORM code in services suffixed with GormService.groovy If you want to call GORM code you have to create a service with such a name.

Testability of GORM. You probably need integration tests for them.

In Grails 3 you can use HibernateSpec to help you unit test GORM code.

If you ask me, I am on the camp that persistence should be tested with integration tests.

Transaction Settings

He recommends:

• make all services non-transactional by default;
• use @Transactional on those service methods (only on the methods, not on the whole class) where it is required.
• use @Transactional on controller methods where it is required.
• Do not call services from taglibs, at least no transactional ones.

They seem like goods convention to me. However, I will prefer to avoid transactional controllers. If I need to call multiple services, I will create an additional transactional service to orchestrate those services calls.

Working on more complex project

rober Peszek reflects on what it is to work on big Grails projects. He talks about:

• Groovy Magic
• Complexity Grails / Spring / Hibernate
• Framework Bugs
• Keeping up with Grails Releases
• Testability
• Performance
• Concurrency
• Community

In my opinion, the Grails team has tackled the problem to "keeping up with Grails releases" in Grails 3. By reducing the release cycle they have made it is easier to update and thus keep running the latest stable version. I have been updating our Grails 3 app for the past 19 months to the latest version successfully.

Grails Testable code

Rober Peszek describes how he barely unit tests in Grails app but he uses heavily Integration and Functional tests.

I am probably in his camp. While I do unit test, Integration tests and functional tests are the tests which allow me to sleep well.