The idea for this blog came from the documentation and answers out there regarding Grails as a platform – or to be more precise – the lack of writing about why and what the different choices brings to the table, and also which choices are there to choose from.

The amount of optional and mandatory choices when entering Grails is overwhelming. Especially compared to a legacy platform where all the choices are made for you.

I have found enough help using guides, slack, stackoverflow and google, to solve most specific challenges.

Today the process is somewhat under way and I acknowledge that some of the earliest challenges are now forgotten.

My background

I came to Grails from Lotus Notes (fat client), later sold out and rebranded IBM Notes, which was enriched with IBM XPages (web browser) platform around 2008. Since 2011 all new development was on XPages.

My company makes standard software for small customers, where production is project based, mostly construction industry.

Our software is delivered as a service, running on our servers.

Why Grails?

First of all we wanted our new platform to be open source.

Second we wanted to be able to reuse at least some of the code written in java.

I was referred to Grails by my brother.

I wrote a couple of small support applications to get feel for Grails. This was enough to go ahead and start the larger move.

Short overview of Domino server with XPages and development platform

The IBM Domino server is java-based, at least the last 15 years or so, it comes with built-in NoSQL database, security, email, ldap and the XPages web server (+quite a few other features).

Data and application is stored in one database instance. Meaning that sharing data between applications is complicated.

The Domino Designer, development IDE, is based on Eclipse and only runs on windows.

The platform is mature and robust. In my 20+ years on Notes/Domino platform I have not lost any data, and down-time have been close to zero.

Reasons for changing platform

Here follows an incomplete set of reasons.

Change to integrated services is not straight forward.

E.g. we needed to manipulate emails and send / retrieve email via other customer servers. This was made very difficult since messaging is integrated and a sub-set of javamail was integrated on the server. The solution was bringing in commons.net smtp and imap services – which is too low-level for me.

The integrated security makes multiple tenants on one server awkward.

Setup and configuration of the server involves many manual steps.

IBM support – I can feel the blood pressure rising from just typing “IBM support”.

The IDE is only available as a Windows. We wanted a native linux IDE.

Next up

In the next blog posts I will walk through the process of putting together a sensible development and production platform.