More on “Where next for Grails”?
Last week Peter Ledbrook wrote a nice summary of where we are at and where we should be going with Grails over the next few years.
He made some interesting points, and it is true that Grails is indeed at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases.
Mobile and Rich web apps are driving this revolution. Many folks are simply serving up JSON to be consumed by rich clients. So where does Grails fit into this world?
First of all, it is worth pointing out that Grails is not the only framework that is going to need to adapt to this new world. Pretty much every current popular web framework is going to have to make changes to support new architectural styles (including some of the official specifications from Oracle). This is already happening everywhere, and Grails is no exception.
However, unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.
Grails is approaching 1000 plugins, the growth Grails has had in this area has been staggering. Many of the plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.
However, when you issue a “grails create-app” command, currently only one architectural style is supported: the Servlet environment. Grails only allows creation of applications served up by a Servlet container. Granted that is a lot of applications (Tomcat is extremely popular), but we believe the features offered by Grails are compelling outside this environment too.
To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year.
Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).
This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.
All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.
Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.