What Grails 3 Brings To The Research Informatics Lab

In my previous post, I talked about the current state of the Grails platform and what it brings to the Research Informatics environment.  In this post, I’ll discuss some of the features in the upcoming Grails 3 release, and the potential impact of those features on Research Informatics organizations.

With the release of Grails 2.3 we gained a new @Resource annotation that allows us to turn a domain class into a RESTful endpoint with a single line of code:

@Resource
class Gene{
   String symbol
   String sequence
}

There were a whole host of other changes in 2.3, which were documented in the first half of the presentation shown below.  In 2.4 the focus was very much on getting Grails up to speed with Groovy 2.3, Java 8, and Spring 4. Including improved support for @CompileStatic which gives Grails classes strong typing.

App Profiles
With each of the releases thus far, Pivotal has been migrating functionality out of Grails and into a whole constellation of plugins. GORM (the Grails Object-Relational Management system) was externalized. The packaging and deployment were also externalized, along with support for static assets in version 2.3.

With Grails 3.0, the reason why this was done becomes more evident. Grails will be supporting the following App Profiles — Netty, Servlet, Batch, and Hadoop. This means that the developer will have greater flexibility in creating everything from microservices, to batch services deployed across multiple nodes in a cluster, to large scale cloud services using Grails.

So if you need to whack out a quick microservice to turn an EUtils service call into a RESTful service call that returns JSON — you could do it with a minimal amount of code and project setup. If you want to do a quick demo, and deploy it as an executable JAR with the embedded Netty server, you could do that. Or redeploy it as a WAR file and run it on your favorite app server.

The technology underlying these App Profiles is Spring Boot. If you’re familiar with Maven, you can think of Spring Boot as a tool for managing archetypes. You specify the type of project you want to create, and Spring Boot sets it up for you. That’s a bit of an oversimplification, but you can get more in-depth info about it here.

Cloud Deployment
Traditionally, Pivotal (and SpringSource, and VMware before them) have had an on-again, off-again relationship with cloud deployment.  Cloud Foundry (the Pivotal cloud platform acquired during VMware’s reign) has been in a long-term beta state for several years now. As a result, the default go-to cloud platform for Grails developers has become Amazon Web Services.

Support for Google App Engine (GAE) in Grails had some initial interest, but it constrained the developer to a specific version and flavor of Java with incomplete support for the standard set of Java APIs.  And this left developers running into problems when code would fail because of missing dependencies in the GAE environment. Moreover, the startup times for Grails in GAE would sometimes cause timeouts. And the result of this was that if you wanted to use GAE, you ended up using frameworks like Gaelyk and Glide instead of Grails.  This led to a certain amount of developer frustration because the whole point of Java development (and Grails development for that matter) is that your deployment platform shouldn’t matter.  It should just work no matter where you deploy it.

Support for App Profiles has the potential for changing that story.  The road map for App Profiles seems to target the most common deployment scenarios (local deployment during development and testing), enterprise deployment and the cloud.  But I can foresee people adding support for GAE and  Docker.

Multi-Project Builds
Traditionally, if you wanted to modularize your code, you created Grails plugins.  They were quick and easy to do, and the process of developing them was largely indistinguishable from Grails web app development.  With Grails 3.0, Pivotal will be adding support for Multi-Project builds.  Making it easier to build and deploy of suite of related web apps.

Event-Driven Projects
Grails 3.0 also promises to deliver support for event-driven programming.  With support for the Spring Events framework, and message routing from Apache Camel, these features make it possible to deploy loosely-coupled, scalable cloud applications.  This has potential applications for developers working on large-scale text mining applications, and next-gen sequencing efforts.

So what are the implications for Research Informatics organizations?

  1. Improved development velocity – with support for @Resource, and REST controller scaffolding, you can go from 0 to 60 in even faster than before.
  2. Improved scalability – using the App Profiles, you can develop everything from a micro service to a cloud service.
  3. Plugins continue to be a challenge — with the architectural changes to Grails in 3.0, it remains to be seen how many of the plugins will be migrated over.  The Spring-related plugins will probably continue to be a safe bet.

 

Advertisements

About aspenbio

I write software for scientists. I'm interested in Java/Groovy/Grails, the Semantic Web and Cancer Biology.
This entry was posted in Bioinformatics, Informatics and tagged , . Bookmark the permalink.

2 Responses to What Grails 3 Brings To The Research Informatics Lab

  1. Sena Gbeckor-Kove says:

    Hi, do you now if anybody has started looking at getting Grails 3 to work on App Engine?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s