A search for meaning in software and life
RSS icon Email icon Home icon
  • Where next for Grails?

    Posted on April 12th, 2013 Peter 61 comments

    A time comes for every open source project when it has to take a step back, reflect on the past and decide where it needs to go next. The world rarely stays the same as when the project was born and in the tech world things change year on year. Back when Grails first came out, Java web frameworks were still a pain to configure and you had to pull together a whole host of libraries to do what you wanted. The use of conventions was rare and ease of use didn’t seem to be a high priority.

    Now in 2013 there are probably hundreds of web frameworks for the JVM, most of which have learned lessons from Rails and its ilk. In addition, we have Node.js spawning lookalikes and derivatives (such as Meteor) aiming to provide lightweight servers that can handle hundreds of thousands of concurrent connections through asynchronous IO. In this world, what is Grails’ value proposition and where should it be heading?

    This is a pretty long post, so if you want to skip straight to my suggestions, head on down to the conclusion at the end of the article. But I’m hopeful you’ll find value in the rest of the article!


    Let’s look at where Grails stands right now. It’s a rapid web application development framework based on the MVC pattern, servlets, and data stores. Once installed, you can have an application running in under a minute. You don’t have to know SQL in order to use a database (although it does help a lot) and you can, with limitations, use the same API (GORM) with NoSQL databases. In fact, most of the components of Grails are now plugins even if you can’t uninstall or replace all of them.

    Here’s a quick run-down of what you get:

    • Data access – GORM (Hibernate, MongoDB, DynamoDB, Neo4J, etc.)
    • Transactions – services, @Transactional, withTransaction {}
    • Business logic – services, domain classes, command objects
    • HTTP – data binding, URL mappings, content negotiation, caching
    • JSON/XML – JSON/XML serialisation/deserialisation, automatic request parsing into params
    • HTML templates – GSPs, layouts, tag libraries
    • Static resource management – Resources plugin
    • Security – Codecs, form tokens, access control plugins (Spring Security, Shiro, etc.)
    • Integration – Spring, REST client plugins, messaging plugins
    • Build – custom, integrated build system
    • Testing – unit test harness, integration testing mode, functional testing plugins
    • Data migrations – database migration plugin
    • RAD – automatic reloading, Groovy, DSLs

    That’s a pretty extensive list. Much is based on existing Java libraries, but even when that’s the case, there is a significant amount of Grails-specific code involved. And all the parts are designed to work together. For traditional web applications, you have pretty much everything you need at your fingertips, and when you need something that’s not provided out of the box, there is usually a plugin to help.

    So, who’s the target audience for this? Beginners? Experts? Somewhere in between? Perhaps both? Is it a RAD MVC framework? Or a platform for building all sorts of web applications? Is it designed to be performant? Or scalable? Is TDD required or encouraged? Is it supposed to work well within larger projects and teams? Or it is mainly for 1-5 person startups? That’s a lot of questions and I could probably come up with even more.

    I think that Grails is currently defined more by what it provides than by what it’s for. What any project needs, just like any business, is a vision. Normally there is a vision for a project at it’s inception, because that provides the drive for it’s creation. Years down the line though, that vision needs to be refreshed. Look at how Apple changed it’s vision to focus on easy-to-use, desirable consumer devices. Google is trying to refocus and develop it’s own vision for what it wants to do. Yahoo! seems to have lacked one for some time now and is suffering the consequences.

    A vision helps focus development and motivate the participants. It also let’s users know where the project is going so that they can make informed decisions about whether to use it or not. Or where to contribute, if they’re eager to give something back. Such a vision was recently articulated by Adrian Colyer of SpringSource in a blog post. To quote:

    Grails 3.0 will separate Grails from the traditional application server and extend Grails’ reach to allow for the development of lightweight, asynchronous applications. Grails’ persistence technology GORM has also been evolving beyond the traditional relational database, with implementations for NoSQL databases now available. GORM will continue to be an important technology for us as enterprise data fabrics evolve.

    Is this enough of a vision? Is it the right vision?

    The truth is, there are many different ways to write web applications these days. More and more of them have rich JavaScript user interfaces that simply communicate with the server over REST APIs using JSON. “Realtime” web applications are becoming more popular too with WebSockets and an event-based back-end. Messaging architectures, CQRS, rich domains, services over REST or SOAP – the list goes on. Should it be possible to code apps like these with Grails? What added value would Grails provide for each of these approaches?

    So many questions. I don’t profess to have the answers but I do want to offer some suggestions in the hope that it kicks off a discussion about what we want from the framework.

    To begin with, developers should have the flexibility to choose different types of architecture while still getting some benefit from Grails. I was struck recently by a talk on using command objects as the primary artifact of the application architecture. Command objects are an underrated part of Grails that can be used in all sorts of patterns and architectures. I have also dabbled with the Platform Core Plugin’s event bus as an alternative, message-oriented backend that can also push messages to Javascript in the browser. Both of these examples demonstrate that Grails already provides features for non-conventional approaches to application architecture.

    Building direct support for lots of different architectures into Grails would be a bad idea. You would end up with a monolithic monster that no one would use. It would also likely be too much for the core team to manage alone. A better approach is to decouple the different parts of Grails into plugins and allow for alternative architectures through community-contributed plugins. This has already happened to some degree, but there is still some more decoupling to do. In other words, the plugin system should become the central part of Grails. Applications then become a collection of easily composed pieces.

    Composable systems like this provide flexibility at the cost of a steeper learning curve and an extra barrier to getting started. One of the great things about Grails is how quickly you can get going with the standard application architecture. It would be a shame to lose that in the process of decoupling the different parts of the framework. The answer is probably a combination of project templates and strong conventions and defaults, where project templates are simply default project configurations with different sets of plugins depending on what application architecture you want. I think it’s possible to make most architectures accessible using this approach.

    I have to admit that this idea of focusing on the plugin system and project templates (or archetypes) is not new, but it does make sense to me. It also raises challenges: who will maintain project templates and the associated plugins? There is no way that the core Grails team can do it. That means the community needs to step in and that’s why there has to be work to make it as easy as possible to contribute, from guides on how to do things to consistent and well documented APIs or other integration points. Fortunately, the act of decoupling the internals of Grails and putting in place APIs will make contributions easier. And the existing GORM decoupling work has shown the way here.

    A vision is only one part of the story. It gives a destination, but what guides the day-to-day decision making? That’s where values come in. Things like “every feature will be documented” or “upgrading should be as automatic as possible” or “the user should never be left waiting.” These can then be codified, for example by having commit guidelines that state new or changed features should never be committed without documentation and integration or functional tests. Such rules are particularly important when you’ve spent lots of time developing and debugging a feature and just want to be done with it. It’s very easy to skimp on the testing and documentation at that point.

    Conclusion (and “too long, didn’t read” version)

    To sum up, I think any project needs to have a clear vision and a core set of values that all committers and contributors must cleave to. I would like to see Grails focusing on being a rapid web application development framework that is accessible but allows for flexibility. Things like performance are important, but secondary. In other words, Grails should aim to reach a certain number of requests per second for a given setup, but it shouldn’t aim to be the smallest and fastest framework in the field (for example).

    The idea of rapid development should come from several features:

    • Near immediate feedback on changes
    • Very few (preferably zero) long wait times (say more than 10s sitting on your hands)
    • Error reporting that makes it easy to identify the source of a problem
    • Conventions, defaults, little to no boilerplate
    • Easy integration with common external systems

    Grails already ticks these boxes to a greater or lesser extent, and to be honest I don’t have major feature requests. Instead, I would like to see a focus on the reloading side of things, even better error reporting for all parts of Grails (the simple stuff is reported nicely, but things like Spring initialisation errors are hard to interpret) and finally a well-documented, straightforward plugin API that plugin developers can have confidence in. Because ultimately I think Grails’ success depends heavily on the quality of the plugin ecosystem.

     

    61 responses to “Where next for Grails?”

    1. Great post. I’ve been thinking a lot about Grails, other frameworks and the future for the last year or so. I’ve been more & more involved in fat client JavaScript applications & sometimes Grails feels too “heavy” for those scenarios. However, it’s easy to forget how much it does for you especially in terms of getting up & running quickly. Trying out other frameworks I’ve sometimes found myself dealing with the kind of setup issues I used to see before starting with Grails.

      I guess my main bugbears are the following:

      1: unit tests for the components of a Grails app feel much more like integration tests. The test support in 2.0 has been a big improvement but when test setup is reading “real” project configuration & bootstrapping a non-trivial pseudo-Spring application context it’s a long way from an isolated, lightweight unit test. When something doesn’t quite hang together in that setup it can be hugely painful to debug as well. Also it has an effect on confidence in unit tests when some things don’t work the same in unit tests as they do in reality.

      2: the build system is a mess. A Gradle build feels like a bit of a pipe dream because of the complexity of the existing system & the backwards compatibility issues but it’s a real breath of fresh air when working on non-Grails Groovy apps that everything runs a *lot* faster & more reliably. Also the strides that are being made in the node community around build tooling are quite inspiring and could give us a different perspective on how to handle static resources, front-end dependencies, etc.

      3: Data binding is inconsistent & surprisingly limited. These is more relevant than ever with fat client apps that can push fairly complex JSON object graphs to the server & that’s the reason I wrote the GSON plugin – because I found the out of the box stuff just didn’t work well enough.

      Breaking changes & regressions have sometimes been painful. I’ve worked a little on the Grails core & the functional tests are difficult to run & don’t feel very reliable. An idea I’ve seen kicked around before is a reference app with a reasonable level of complexity & really good test coverage that could serve to smoke out these kinds of issues before release.

      It would be great if Grails could make the dependency on GSP and Sitemesh optional. These days doing your entire UI with JavaScript is a very viable option & having the ability to streamline things a bit by dropping traditional server-side rendering would be cool.

      Taking that further, I’d love to see Grails as a kind of highly-modular construction kit for your server-side app. There have been some strides in that direction but there’s some tangled interdependencies lurking in the core (and between certain plugins). It would also make the idea of a reference app much harder as no one setup would be ‘typical’.

      Without a doubt GORM is the jewel in Grails’ crown – especially with a no-SQL store when you can escape the depth of knowledge you need to have about Hibernate in order to get the best out of it. With that and some of the other really good features (URL routing, convention-driven DI, etc.) there’s a lot going for the platform.

    2. This is a great article and your conclusion is a match for what I think of when advocating for the use of grails on any particular project. I love grails and have been thoroughly rewarded for the 3 years that I have used it. I think that the biggest let downs for me in grails are:

      1. How fragile reloading is, often broken by plugins
      2. Memory requirements are out of control and getting worse in each release.
      3. Application startup is slow, easy to make slower during application development and extremely hard to diagnose.

    3. To echo Rob’s statement, I find that I’m using Grails to handle the backend of my apps- the JSON / REST interface to complex data and actions, and the easy scaffolding to build the admin tools.

      I’d love it if the robust Ajax support could move into angular / backbone / rich backend bindings.

    4. Great post. Time shows that ORM is not good way for building larger apps(query with more joins), people in RoR understand that and DataMapper is new cool stuff. In java ecosystem we have datamapper- mybatis, but only few people know it. Im my opinion gorm particularly in relation databases(it means gorm,hibernate) is bad direction.I work longer with hibernate and when compare advantages/disadvantages it gives me not use hibernate, or hibernate like solutions eg. gorm, GORM is another abstraction with focus on simplicity but with another complexity, but GORM for noSQL can be good(I don’t use it). It exist plugin grails mybatis but is very poor, eg. it hasn’t support for annotations. I post also quesstion on forum but without reaction. And it’s another problem, I think that for springsource and another companies living mainly from consulting, isn’t good to answer for many questions, because it doesn’t have sence for paying support. There are different types architectures, but persistence(mainly relation DB) are key for major webapps. For now absence full support mybatis on grails is for me reason why prefer classical spring mvc.

    5. Improving stability should be the main goal.

      I’m going back to working on a Grails project after a year of mostly backend programming on top of plain Java / Spring MVC and I’m already dreading the bugs and edge cases I’ll have to deal with on a weakly basis.

      Simple built-in diagnostic options would be nice to identify bottlenecks. Perhaps something like the Metrics library: http://metrics.codahale.com/manual/

    6. I love the vision statement that is out there. I am glad your parent companies visions don’t seem to be influencing Grails’ trajectory.

      We are a small products shop in Bangalore, India ( http://www.muhive.com )depending on Grails to do all the heavy lifting for us. For those times when we need to build a backend system, we flex our java/groovy muscles and love the fact that Grails can communicate to these backend systems via a rich set of messaging tools and plugins on the grails eco-system.

      I was half expecting cloudfoundry to steer Grails in the direction of a PaaSy framework. I am glad they have been delineated in their purpose. Kudos to you guys and keep up the good work. We will try and make Grails the best framework out there with our plugin contributions :)

    7. Thanks for putting these questions out there Peter.

      As you know Stéphane Maldini and I have proposed this kind of “Grails as a framework platform” idea for a long time now.

      From my point of view, and I will speak bluntly and perhaps painfully here for the benefit of Grails I hope…

      1) I don’t give a rat’s ass about async stuff, and none of my clients do to any significant degree. Yes it should be supported by this is in no way a mass market feature, but this is really minority stuff. Few people make *real* apps that need this or need the scale facilitated by this, there are many frameworks that do it already, and it is largely hype. Grails allowing you to create these different kinds of apps through a well designed generic “profiles” (or archetypes) API would be a good thing.

      2) Currently using Grails 2.x is quite stressful. As the years have gone by it has become less and less attractive because of the mounting bugs, myriad reloading problems and dependency problems. This is horrendous when performing work for clients because the problems can be so obtuse and difficult (or impossible at times?) to solve, that when you are consulting for people and you have to explain this, it makes Grails look very bad. The slow release cycles make this excruciating.

      3) It is increasingly hard to recommend Grails to clients because of the above issues and the lack of experienced Grails or cost-effective Java developers in the market place. It doesn’t matter how good something is, if you can’t find people to do the work, it is smarter to choose a framework that has more people out there with the skills. This is not directly Grails’ fault, but it is Grails’ problem, and it is a side effect of lack of mass adoption. Mass adoption is critical.

      4) Most recent changes have been very incremental. As I’ve stated in talks etc. before I believe the only way to leapfrog other frameworks is to provide much higher level features and productivity gains. New ways of querying a DB, or even a faster DB layer, whatever… are incremental things. Create app. Install “users” plugin and “theme” plugin – and bingo an instant runnable app with signup, login, user profiles, professional out of the box customisable theme etc. THOSE are the things that will get new people in.

      As you know I tried to make this stuff happen with platform-core, platform-ui and fresh-security… but there is no money to be had contributing such ambitious projects. The Grails project needs to own these high level things so that relatively simple but potentially impressive plugins like fresh-security can be created easily by the community.

      App scaffolding is the new frontier, not async tech of 3 years ago.

    8. @Ritesh Perhaps I should clarify that I no longer work for VMware (and haven’t done so since late November 2012). My suggested vision is just that: a suggestion from a member of the community. I do not speak for SpringSource/VMware/Pivotal in any way.

      With that out of the way, thanks for the feedback :)

    9. Roberto Guerra

      Great blog post. I think focusing on a low barrier of entry is bad. Very bad. Getting an app up and running in seconds is bad, very bad. It should focus on providing options to build modular and scalable apps. Having archetypes would help for newcomers, but having options for power users is also necessary. Because once the honey moon is over, and the framework starts to restrict you, those powere users will migrate.

      As an example, the Pyramid framework in Python. It is much more difficult to get started with than Django or Grails, but it also provides archetypes for newcomers. Eventually though, one appreciates the flexiblity and power it offers and don’t need the archetypes any more.

      I think GORM is a headache. Yes, for very simple queries it is nice, but for any relatively complex application it gets in the way. It leaks into the application. I like the way the ORMs work in Scala and Clojure frameworks. It allows you to decouple the application from the persistence aspects. GORM is fashioned too closely after Active Record, and if you read any of the recent posts by rubyists regarding ActicRecord, you will realize how terrible it is for big applications.

      Finally, total number of users does not equate to more contributions from the community. The Pyramid framework is a good example. The Pyramid irc & mailing list is much more busy. The barrier of entry to submitting pull requests is much lower. Sending a contribution to grails feels like some bueurocratic process. Even filing bugs is a pain. You have to register at github and Jira. That is a turn off. Even subscribing to the mailing list is a pain. It feels as if they are doing everything possible to dissuade the growth of the community.

    10. Like Robert and tim, I tend to use more and more Rich client web app. Working on mobile app, when you want to package to Hybrid you want to deal with HTML and JavaScaript only.

      Plugins we’re writing for Grails (3musket33rs), as I always says take Grails on the wild side. We’re working without GSP, scaffolding Controllers that render JSON, and Views as HTML5 with MVW pattern.

      I wish we could have an smoother integration with Grails. If Grails could focus more on being a plugin platform and enhance its REST support that would help our plugin development and let you choose a fat client side(a modern client!). I like the idea I’ve read above about plugins profile.

      Going asynchronous is the ultimate responsive UI to me. I’d love to see all the good stuff it will brings to Grails. Personal views of course.

    11. @Roberto You make some good points there. I disagree with you about the low barrier of entry because I don’t see an inherent conflict between a shallow(ish) learning curve and powerful tools. Convention over configuration is one mechanism for combining the two, as are a modular approach and the concept of project templates. I think Gradle demonstrates that the two can coexist: straightforward builds are very simple, but there is no denying that Gradle is a power tool.

      To be honest, it looks like Pyramid may be more of a tool than a framework. Of course, it depends on a person’s interpretation of ‘framework’ and ‘tool’ :) But I certainly think there has to be a definitive choice about whether a project is a framework (with inherent rigidity) or a tool (with more flexibility, but little inherent structure).

      BTW, I love the fact that the Pyramid project has a list of tenets. That’s exactly what I would like to see for Grails.

    12. Roberto Guerra

      @Peter Yeah, I guess you are right. It is more a tool than a framework. There are frameworks built on top of it, but I’ve never used them. To quote a poster from the mailing list: There are no Pyramid developers, only Python developers that use Pyramid.

      A killer feature would be the ability to convert a model from the backend into a model in the frontend. That would mean it would settle for a Javascript framework, but then that could be a plugin. If it is done right, the core team would only have to write the interfaces and the community can use those to write specific implementations. This would enable us to use the same model in the backend and the frontend. The backend model shouldn’t be tied to GORM tho, because at times you want to pass a View Model or Presenter, and not the database record. I think this is what Yehuda Katz is trying to do with Emberjs in Rails. It sounds like a good idea, but I guess we wouldn’t know until we actually get to use it.

    13. Roberto Guerra

      Another thing that is sort of obsession of mine is to have a modular app. I want to be able to write the business logic as a Groovy project. This way I can test it without Grails and just plug it in when I need to deploy and run integration tests. Because of GORM, I have not been able to do this.

    14. [...] Ledbrook has written an excellent post on his vision for where the Grails framework should move towards. There have been some excellent [...]

    15. @Roberto As far as I can tell, the only thing that is even remotely confirmed for Grails 3 is moving to Gradle for the build. Even that’s not 100% certain. But that would make it much easier to do modular projects in the way that you want.

    16. Excellent post and done at the right time!

      I believe that there are two main concepts and guidelines in you line of thought, with which I agree absolutely and categorically, these are:

      - developers should have the flexibility to choose different types of architecture
      - decouple the different parts of Grails into plugins (plugin system should become the central part of Grails)

      I think that this sentence is crucial:
      “The answer is probably a combination of project templates and strong conventions and defaults, where project templates are simply default project configurations with different sets of plugins depending on what application architecture you want”.

      At first it seems difficult to successfully reach such a paradigm. But this is where I want to contribute w/an idea. Before Grails I developed many apps during +20 years with Topspeed Clarion RAD. Anyone who knows this IDE & language knows that its main feature was the “generation of app via templates” (30 years of progress in this paradigm). Clarion Templates are casually “code that generates code”, like scaffold scripts of Grails. Also, you choose the app architecture (called “chain templates”), and much more. But also has a feature that overcomes: templates have multiple options according its destination & goal (with defaults) that enable the its selection and are saved between generation and generation of artifacts.

      Nothing better than an simple example in Grails way … assume that “generate-views Person” we ask:

      -> Which columns you want in the list (username + email) ([y]-n)?: n
      -> Username ([y]-n)?: y
      -> Last name (y-[n])?: y
      -> First name (y-[n]))?: y
      -> Email ([y]-n)?: n

      Although this implementation would be cumbersome in Grails, but helps to understand. In the next run of “generate-views Person” would look like:

      -> Which columns you want in the list (username + Last name + First name ) ([y]-n)?

      …because my previous selection was saved!

      Now I don’t saturate the post with technicalities, but I ask you to imagine the following framework:

      An IDE that takes the “chain templates” selected (architecture), that enables fast and convenient editing of those only will be changed choices, that reads the previously choosen or defaults in template). Then run a generator (script). If you do not like something, change it (re-edit) and run the generator again. Just edit what you want to change, that is, a couple of things from hundreds of options!.

      I confess that this was a dream I had one year ago, so I have developed a couple of plugin that point to this. Due to time I could not move forward with the IDE, but I came to realize the “generation engine” (scripts plugin) and some templates for test. In my github there an explanation (although light) the first goal I raised at that time.

      Peter, if you are interested in this idea, I will gladly willing to share and expound more features, like:
      -Artifacts can be html, javascript, groovy and other files.
      -Artifacts generation is procedures oriented.
      -Favors the division of roles (web designer, grails dev.)
      -etc

      I hope you have understood me :-)
      regards

    17. I’ll just add another thing here.

      What was the very best thing to happen to Grails in the last 12 months, from a developer perspective?

      Without doubt, GVM.

      The success of these frameworks really is dependent on the developer user experience.

    18. Great Post!

      My main wishes for grails are pretty similar to most people on here.

      1) Redoing the build system.
      2) Better REST support which I hear is a main focus of 2.3 and I’ve seen some good comments on what is coming.

      After that, I want Grails to focus on what it does best which is I think being a convention over configuration MVC web framework. It doesn’t have to support all the asynch features of vert.x or the web service features of dropbox. I worry that grails will try to include everything but the kitchen sink. That said, allowing people to use GORM within vert.x or a groovy base dropwizard application seems like it could be useful.

      To accomplish these goals, I’d like to see:

      1) Better support of javascript and css as part of the framework. LESS, SASS, and CoffeeScript don’t get much love in the grails ecosystem. I want them to work out of the box.

      2) Better documentation around the ‘right’ way to build grails apps. I see too many examples with transactional code in controllers instead of services.

      3) Focus on growing the community.

    19. I forgot a few things:

      I’d like to see grails steal a few ideas from dropwizard to incorporate into the framework namely:

      1) smarter defaults for logging formats and exception logging
      2) bake metrics into the framework on some level.

    20. Roberto Guerra

      @Marc Very true. The small tools are many times the best. :) The Unix Philosophy never fails.

      I think Grails’ weakness is its size. It is trying to do too much. Marc is right, focus should go to building plugins. Grails core should be small, stable and reliable. To me, it should really just be a ‘delivery mechanism’ for an application.

      Being in the jvm in these times is golden, but there really isn’t a framework that takes advantage of that yet. I think Grails is definetely the best web framework, but it should stop trying to be everything. It encourages monolithic apps. My dream framework is one where I can write a module in Clojure, another in Scala, or Groovy or any JVM language, and then just dump it into Grails and wire it together with Services. In theory, this should be possible (without needing a Clojure/Scala/JRuby plugin). I should then be able to write my views as a separate Javascript/Coffeescript/ClojureScript application or with traditional gsp.

    21. Peter,

      could you suggest few project templates? I know only 2: Web application (war) and background application (jar). At the moment the second one should be implemented as Spring app – I want use Grails for it but I don’t need web part of Grails.

      I like Grails but I have few suggestions to improve:

      0. As I said background services can’t be implemented as Grails application because it creates WAR.

      Suggestion:
      Give us an ability to create JAR application. Most of the plugins (which doesn’t use web part) should still work.

      1. Grails build system – the worst part of framework.
      1.1. When I add/remove plugin/dependency I’m expecting to have problems – to clear ~/.grails/…project folder.
      1.2. Grails + Maven… Complex + Complex = Super Complex. To understand what happens you should know Maven, Grails and how Grails interacts with Maven. Fail.
      1.3. _Events.groovy. I’m pretty new to Groovy and Grails but I still don’t understand why it’s implemented this way? How can I hook into process X? Where can I find all list of events?
      1.4. Dependency resolving system. Even 2. A lot of cache folders. When you add Gradle we will have 3 ways to resolve dependencies (Ivi, Gradle, Maven). Do you think that I understand how does each of them work?

      Suggestion:
      1. Everybody is asking you to “break” everything and use Gradle to build Grails project. Developers should know only one thing (Gradle) to build Grails project.
      2. Add more “hook points” for plugin developers
      3. Document all “hook points”

      >Near immediate feedback on changes
      >Very few (preferably zero) long wait times (say more than 10s sitting on your hands)

      Yes, Grails has it already. But does it work? May be this is Grails bugs, may be bad plugins implementations but this coolest feature doesn’t work. It may work in situation X, but doesn’t work in situation Y. You change something and you don’t know will changes be reloaded or you should restart your project. This is sux.

      Suggestion:
      1. Review each plugin for correct work on run-app changes or
      2. Add flag “may have problems with reloading” on plugins page. When plugin has problems users will be able to indicate about them
      3. Provide more documentation for plugin developers. Each time you say “plugin ecosystem” but documentation is really sux. Few words about doWithApplicationContext, few words about doWithSpring, nothing about onConfigChange

      >well-documented, straightforward plugin API that plugin developers can have confidence in.

      There are a lot of Grails plugins. Few of them doesn’t have bugs. Plugin development is hard. Grails plugin development is super hard because of:
      1. There is no books for plugin developers. http://shop.oreilly.com/product/0636920024750.do has cool chapter but it’s not completed and it’s not enough
      2. Documentation. Without comments

      At the moment the best way learn plugin development is to read sources of other plugin

      To summarize:

      New:
      1. Gradle
      2. War / Jar

      Improvement:
      1. run-app reload
      2. documentation

    22. I beleive that grails is already a nice beast, but here are things that could be improved:

      - More modularisation; A little bit like they did with symfony 2, where you can defines youre bundles, your templating engine and so on.

      - Async is nice, but it nowhere near that important, for most projects its not event a requirement.

      - Rest is not supported enough. Grails is nowhere near restful and that’s a shame. But i beleive grails is already going in that direction. HATEOAS, headers, hypermedia, etc

      - Binding. Indeed, complex object binding should be supported by default. Right now, it’s just not working and we must use xstream.

      - gradle, gradle, gradle…

      - security? i am scared to ask…

      - default logging configuration is ugly

      - rad single page app development

      -Something that would be nice is a configurational grails build. «a skeleton generator» i.e.
      - i want a restful grails with spock, mustache, angular, etc
      - i want a restful grails with spock,
      backbone, underscore, etc

    23. [...] Peter Ledbrook: “I think that Grails is currently defined more by what it provides than by what it’s for. What any project needs, just like any business, is a vision. Normally there is a vision for a project at it’s inception, because that provides the drive for it’s creation. Years down the line though, that vision needs to be refreshed.” [...]

    24. Hey Peter,

      I’ve written up a rather involved reply to this awesome blog.

      http://www.simplicityitself.com/article/future-of-grails

      Cheers dude,

      David.

    25. I would love to have a more modular grails, where it becomes a platform instead of a spring mvc wrapper; having solid REST support would certainly make my life easier. But without Marc Palmers second point being addressed, I am not sure any of this matters. The dependency management system has embarrassed me during training and presentations, making both me and grails look bad. Reloading has enough bugs that errors are hard to decipher…. ie is this issue a programming error or a grails bug. These 2 issues are major adoption blockers imo. People will pass on cool features for a smooth development experience. I actually wish 2.3 would skip all new features in favor of improving the development experience.

      All this said. I love Grails, and I stubbornly push it as much as I can despite its warts.

    26. Thanks a lot for this blog article. Definitely agree with many of your propositions out there. My wishes list for the future of grails is simple :

      - better integration with Ajax/JavaScript/Rest/Single-page-app : currently no obvious solution for building a Web2.0 app if you go with grails. Make it the best integration platform for this kind of apps, and all of the JVM enterprises will embrace grails because today there is no solution in JVM space

      - RAD : reloading, refactoring, modularity, stability. Whatever make you development easier and better. Again, if Grails does so, it will be first choice in java web framework

      I’d like to add my opinion on Grails vision : the JVM is its core provider of customers…and therefore it should strive to be the best platform for new applications in java space (node.js, ror or whatever are not direct competitors of Grails)

    27. Roberto Guerra

      Another inconsistency: tests. Test code should be almost similar to production code, and with grails this fails badly. I spent hours today tracking down an issue where my unit test passed, but it wouldn’t work in production because of some Grails quirks. This alone makes TDD with Grails a terrible experience. Thank the Spock Gods for Spock to ease our pain.

    28. [...] Ledbrook ha raccolto alcuni pensieri sul futuro di Grails sul suo [...]

    29. [...] Ledbrook wrote up some thoughts about the future of Grails on his [...]

    30. Hi Peter,

      I really like Grails and had contributed to the plugin ecosystem (simpleDB and dynamoDB GORM). Yet the notion that some core functionality will be extracted into plugins and will be just supported by community is a dangerous one IMO.

      Instead, it would make more sense to me if SpringSource actually committed to sponsoring of development and maintenance of key plugins.

      To put it another way: what is the full-time equivalent number of developers budgeted for 2013 and 2014 for Grails ecosystem by SpringSource?

      I this number would give a much better direction about the future of Grails, wouldn’t you agree?

    31. Hi Peter,

      First of all, I’m writing this with the best possible intentions since I respect you so much.

      You probably remember I used to hate Grails so much that I’ve even written an article on why I preferred Rails over Grails.

      While it is still true that I still do prefer Rails over Grails, that article is no longer relevant for most parts. Grails was a pain to use in the pre-2.0 era where each change to the domain classes would reboot the application and that was driving me crazy. The new reloading frameworks in 2.0 was certainly *THE* biggest feature in 2.0 for several years.

      So, as I don’t feel inspired enough to write another long article, let me try to state my updated opinions on Grails. First I’d like to comment on ActiveRecord for Rails since another commenter touched the subject. The reason why I don’t use AR myself is not due to its architecture. I now do like it, since it was based on Arel when Rails 3.0 was released. But unfortunately it was exactly this release that trashed an awesome documentation about it. Also, the API is quite limited because the Arel API is not public and code that currently works on AR may not work in the future without any deprecation period since Arel’s API is not considered as a public AR API. And the main reason I don’t use AR is because Sequel implements a very similar (even better) approach but with an awesome implementation and documentation and great support in the mailing-list. So, I’d disagree that AR doesn’t fit well in big projects. I just don’t use it because I find Sequel to meet better my expectations of what an ORM should be like.

      Now, to the main subject: Grails. Before I forget, the main reason I currently don’t like Grails is its support. Take a look at this ticket I’ve created over an year ago and never got feedback although I still consider it a blocker one and even provided a reproducible test case in that time:

      http://jira.grails.org/browse/GRAILS-8994

      Several releases have made available since then, both minor and major ones, and this serious bug is still unfixed.

      Since it was affecting my application and I couldn’t find any work-around, I started a Rails application and forwarded the affected actions to it and started using a proxy to forward those requests. This is how the Rails application I currently maintain was born. After that I’m doing any new development (or rewrites) in the Rails app and the plan is to get rid of Grails at some point…

      But I’m still using Grails, so I still know what are the current pains with Grails. The biggest issue after Grails support is the SLOWNESS!

      It is too slow to boot a Grails application. It is over 10 times slower than booting my Rails app. Also it requires much more memory which is making me consider buying another motherboard that will allow me to have 16GB (mine will currently only allow for 8GB). Of course Grails is not requiring that much RAM, but it will require about 710MB (1.5GB virt) while the Rails one will require only about 73MB (289MB virt).

      But being that slow is specially important if you need to run integration tests. I doubt anyone there doing Grails development is practicing TDD because it would be totally unproductive. I don’t really mind about TDD as I only practice it 1% of the times and write the tests after the implementation most of the time. But in the case of Grails, I simply skip any tests that should be written as integration ones. And unfortunately, this includes any test that would touch the database.

      In my Rails application, booting the application itself takes less than 3s, but when I’m only writing tests that touch the db but doesn’t rely on Rails, I consider them unit tests and I don’t boot Rails to run them. I only need Sequel and the related code for my tests so it runs super fast even if it needs to touch the db.

      Also, even the Grails domain classes mocks that should speed up the unit tests don’t work well. For instance, obj.associationId won’t work on mocks (at least this used to be the case) while obj.association.id would. But obj.association.id would be much slower in the real application, so I had to decide between being able to test my code using mocks or write it to perform better under production :(

      Let me also state it once and for all: Groovy is not the issue in Grails. I feel Groovy is too close to Ruby as a language, although its API sucks so much since it tries to reuse Java’s API which really sucks… But even with its bad legacy API with a few improvements, Groovy is still not the pain point of Grails.

      Also, it makes it hard to get contribution from Grails end developers since most of the Grails code is written in Java. It also passes the message that Groovy doesn’t perform well because otherwise most of the Grails code would have been developed in Groovy itself. Why not using Groovy for most of the Grails implementation to lower the barrier for contributions? Also, the test suite is really badly organized and the code is just as bad organized with very long methods (at least it was the case the last time I checked, last year).

      Also, I believe Grails is half baked. Everything seems to half work only… Take for instance the “resources” plugin. Even though I prefer the Rails Assets Pipeline approach, where you specify the dependencies as special comments in the file headers themselves, the main problem with the “resources” plugin is that it is half baked. For instance, you can’t use CoffeeScript, SASS or some other precompiler with it directly and be able to use a “developers” mode that would simply compile those files without minifying and concatenating for instance.

      And the “resources” plugin is no longer maintained by its original author. And it should be considered a key plugin, not just any plugin. The Rails Assets Pipeline is really the feature I most currently love in Rails. And it is probably the main advantage of Rails over many Ruby alternative frameworks.

      Another issue with Grails is that minor releases will often break backward compatibily from my experience. This should never happen. It also smells how good Grails test-suite is, after experiencing so many regressions, even in minor releases.

      Finally, GORM really sucks! It gets on my way too often. HQL is too limited to me and I don’t really need to support any other RDBMS than PostgreSQL. I want to be able to use my PG-specific SQL whenever I want without fighting GORM everytime. I need to be able to provide custom SQL in an easy way, while still using an OO API. Take a look at the wonderful job made by Ruby’s Sequel gem:

      http://sequel.rubyforge.org/documentation.html

      This is one of the best projects I’ve seen in my entire life. Don’t have a single serious complaint about it, which is rare from my experience with other projects. Even for Rails I have lots of complaints.

      And if this limitation wasn’t enough, GORM should completely abstract Hibernate from you. I mean, you should never have to worry about sessions. You could if you wanted but the problem is that if you try to use a domain class outside of a controller’s action, where the Hibernate session is automatically injected, you’ll have troubles. Think on spawned threads for instance.

      In my last article, I said that Rails documentation was superb and the Grails one sucked. And it was true. By that time! Rails 2 documentation was awesome. Grails’ one was terrible. But it seems the situation is totally the opposite now. I find the current Grails documentation pretty good, and I’m pretty sure you were responsible for this shift in the Grails documentation shift. And, on the other hand, the Rails team did an excelent job in trashing what has once being an excelent documentation source. So, I’d like to congrat you on that. Those are the only real 2 big improvements I’ve seen in Grails in the last few years: better documentation and no need for rebooting the application each time you modify a domain class. Yay for that!

      P.S: there is still another Grails bug affecting my application that is preventing some associated object from being removed even though it doesn’t throw any exceptions but this is hard to reproduce in a test case. So, instead of spending some time trying to create a test case for it, guess what? Yep, I’ll prefer to rewrite the affected actions in the Rails app, since it will be much faster… Also, I’ve searched Grails JIRA and I’ve found some similar reports on that issue. And the last time I took some time to write a test case for a critical issue it got just ignored. Luckily, I started the Rails application in the same day I created the ticket and it was running and working less than a week after that. On the other hand, over an year later that ticket is still unfixed and ignored :(

    32. Sorry, I said I could only see 2 major improvements in Grails in the last years. Actually there were 3. I really liked when the “resources” plugin came out. Unfortunately I had to fight so many bugs with it in the past and I still can’t use CoffeeScript directly with it due to the problem mentioned previously. But that’s fine since I can use another plugin that will simply automatically compile my CoffeeScript files in JavaScript ones, which I ignore on the VCS. This is a good enough work-around and I really appreciate Marc’s work on this plugin.

    33. @Jorge Code generation is one way of building apps, but I don’t think it should be part of Grails core. I’m not familiar with the types of projects for which a code generation approach works. It’s probably something that would work as a plugin or set of plugins.

      @Kyle What are these smarter defaults for logging? You should raise that request on the Grails’ JIRA.

      @Fedor Example project templates:

      1. Straight MVC with server-side rendering and DB (classic Grails)
      2. Remote services backend (no DB), otherwise classic
      3. REST service with rich-client UI (perhaps Coffeescript, LESS/SASS)
      4. Event-based, ‘realtime’ apps

      @seb If you think Grails isn’t RESTful enough, you should definitely weigh in on http://jira.grails.org/browse/GRAILS-9888

      @fabien That’s the kind of decision that Grails definitely needs to make, because it does have an impact on decision-making. I think that Grails should compete with Rails, Symfony, etc. but as long as Grails has a clear vision on this front, that’s the important thing.

      Just to clarify, do you think Java developers should be the main/only target audience for the framework? Or are you saying that Grails should simply be the go-to web framework on the JVM?

      @Roberto The Grails 2.0 unit test framework improved a lot, but ultimately there will be situations where unit test behaviour doesn’t match runtime behaviour. Unit tests will never be able to catch all bugs. I’d argue that the real issue is that it’s not clear what the limitations of the unit test harness are, i.e. devs don’t know when they need to switch to integration/functional tests.

      @Roman The number of resources that SpringSource provides for the project will definitely impact how much the core team can commit to. My argument is that a monolithic core cannot scale with the size of the core team. Also, focusing on decoupling the plugins and tidying up the APIs will make it easier for people to contribute to the core (and core plugins) even if the core team maintains overall responsibility for them.

      Any project requires juggling of priorities, resources, etc. I think that without a vision, that juggling can end up being rather arbitrary. Hence why I think it’s important to define the vision first.

    34. @Rodrigo I think you’ve always provided some just criticism and it’s been useful to have somebody from a non-Java background give feedback, even if it’s been quite harsh :)

      This comment was a bit of a vent from you (fair enough) and off-topic for this thread, but I’ll respond to some of your comments:

      1. Yes, some stuff gets fixed and other stuff doesn’t. I think it partly depends on when an issue is submitted, the quality of the subject line and how clear the description is in detailing how severe a particular issue is. I suspect the triage could be improved.

      2. Yes, the startup time is relatively slow, hence why we have the interactive console that improves this dramatically. The trouble with the latter is the reliability of reloading in certain situations. But I find it pretty effective for integration tests.

      3. I think you’ll find it’s possible to selectively enable and disable mappers. There is also a global debug mode. But let’s be honest, those languages and tools usually come from the Ruby or Node/Javascript camps, so it’s not surprising that Rails/Node have better support here.

      It’s also important to point out that the Resources plugin is now treated as a core plugin.

      4. It’s nearly impossible for GORM to hide Hibernate and I for one think that trying to do so can make things worse. Also, many people love GORM :) It’s a case of horses for courses. And you can always uninstall the Hibernate plugin and use something else. Unfortunately, the alternatives aren’t that great (for SQL databases).

      What I would be most interested in from you though is your thoughts on where you think Grails should go from here. Should it try to appeal to Rails users? Does a more modular solution fit your needs? Should it focus on being an MVC framework that mirrors Rails’ approach?

    35. I noticed I don’t get any notifications by e-mail when you reply me, so don’t be surprised if I don’t answer your questions at some point :P

      Sorry if I seem harsh but it is probably true. Not only I dislike Grails very much but I’m also too nervous about my daughter that’s about to be born any time and I can’t help it but saying everything that comes from the top of my head…

      I don’t think Grails should be targetting to be like Rails. You see, Rails isn’t perfect. Far from it. Grails, like any other web framework, and even Rails I should say, should try to be much better than Rails currently is.

      For instance, applications have changed a lot since Rails was born. I don’t write the same web applications I used to several years ago. Currently it makes almost no difference what back-end technology I use because most of my work is spent in the client-side. And I believe web frameworks should realize this shift in web programming and adjust accordingly. Also, I never really liked REST and never used REST in Rails. Most of my Rails and Grails actions return either a JSON response or a status code.

      Rails makes it easier to work with this kind of application through the Assets Pipeline, which works great. You see, I never enjoyed JavaScript but for a long time I didn’t have any options. Browsers still don’t understand Ruby or any other language than JavaScript.

      But recently I have a much better option: CoffeeScript. This is what I write most of the time. Unfortunately CS can’t fix all issues with JavaScript, specially the lack of a require/import statement. This is probably the main reason why I loved the way the Rails Assets Pipeline worked from the beggining.

      From a production perspective, it doesn’t make much sense to load JavaScript dependencies on demand. It would be too slow for most cases. With the Assets Pipeline and the Resources plugins, this is better handled by providing some way of specifying the dependencies among the assets. But the Resources plugin approach is inferior in my opinion. I don’t want to specify the dependencies in some AssetsResources.groovy file. I want to be able to just use require/import-like statements in my assets sources just like I always did in every other programming environment.

      The Rails Assets Pipeline allows me to do that by using comments like this in CoffeeScript files, for instance:

      # =require ./dependency
      # =require_tree ./dependencies

      This is awesome. It makes developing for the client-side much less painful than it used to be before the Assets Pipeline. This is, in my opinion, the main reason that puts Rails above the alternatives nowadays.

      Another killer feature of Ruby projects over Grails is Bundler. This is an awesome dependency resolver system that will even allow us to use gems by specifying git paths, which makes it pretty easy to fork some project, fix it and use it until your pull request is merged in the original project. This easy is something I miss a lot in Grails projects.

      And when I was talking about support, I was serious about it, not just a vent. I’ve reported a few bugs on Rails this year and I got feedback from all of them in within an hour and most of them were fixed in just a few minutes.

      On the other hand, there doesn’t seem to be any triage on Grails tickets when planning a new release and when I demonstrate a serious issue with a reproducible test case included, it doesn’t get any feedback. Simply plain ignored. Now that I brought attention to it again, guess what? It has been marked as “Not a bug”!! Really? WAT??!! Yeah, “not a bug”!!! Man, I can’t take a framework like this as a serious one. It is clearly a bug. And a very serious one. Pretending it is not a bug doesn’t help at all.

      With regards to the interactive console, I’ve tried it. And even though it is faster than running the commands from the console, it is still damn slow.

      Finally, community is important. As you said, GORM has no real alternative in the Grails world for RDBMS. In the Ruby world, if you don’t want to use ActiveRecord in Rails, you’re free to choose DataMapper or Sequel, for instance. And both work great and have a unique community supporting those gems.

      You have a book written only on BDD subject on Rails. It is called The RSpec Book. And you have gems like factorygirl, rspec, capybara, konacha and many more covering all kind of tests you could think of. And they run pretty fast. And they are pretty well documented. And they’re written in Ruby, which makes it easier for anyone to contribute to.

      It is not that I love Rails. As I told you, for the kind of application I write, I don’t need much from a web framework. The main reason I stick with Rails is the Rails Assets Pipeline. I don’t think it is a web framework’s concern to talk to databases. That’s what I use Sequel for. They’re separate concerns, and I’m able to test my database access without relying on Rails at all. I’d say it would be pretty simple to port my Rails application to any other Ruby framework that supported something like the Rails Assets Pipeline.

      So, although you saw my earlier comment as simply harsh, it isn’t. I really exposed the real, main concerns I have about Grails. Just read it as “things that should be improved on Grails”. I don’t have any personal issue with the Grails brand. If it gets good at some point it will be awesome, although I doubt that will happen some day given my previous experiences on how the core team treats their tickets and complains.

      I don’t really care about modular solutions. I care about my own application design and if I’ll make it modular or not. I see the libraries I use as black boxes, although I’d love to see them well written in case I need to investigate some issues and contribute back to them.

      I don’t think Rails or Grails follow the MVC pattern, since common HTTP is a one-way communication essentially. The view doesn’t communicate back to the controller in the same way the original MVC pattern describes it.

      If you think GORM shouldn’t hide Hibernate, I guess it shouldn’t even try to. Because it would force me to understand how Hibernate works and I would know all the issues I could face which I don’t when I use GORM. And then someone just replies me that that behavior is not a bug because it is the way how Hibernate works. If I’m assumed to know how Hibernate work, then please don’t hide it at all. This ends up with a half-baked solution.

      Also, I don’t see why it wouldn’t be possible to make it easier to use direct SQL snippets in GORM with some custom implementation, aside from Hibernate.

      With regards to your note 3, did you try it? Could you provide a sample application demonstrating how to use the “debug” mode with some CoffeeScript source?

      Thanks for caring about this.

    36. Ah, I just remembered another tool that is great on Rails but awful on Grails: the interactive shell (grail shell). It is a terrible experience to work with the Grails shell while irb works perfectly in a Rails application.

    37. @Roberto Guerra: I could not agree more, with everything you say in here.

      IMHO Grails biggest problems are:
      - Active record in GORM, and the shady joke of @Mock annotations, as a way to handle it in tests (which slows unit tests by 2 orders of magnitude in comparison to mocking a repository with only the things we need)
      - No modularity whatsoever (We have tried using plugins for that, but because of how slow the unit/integration tests work in grails, we had to move back)
      - Grails run-time and integration test-time inconsistency.

      Making TDD hard and slow, with no modularity, makes Grails a bad choice if you are building a big application. We have somehow mitigated this by building micro-services, but you can only go so far.

      All the time we have saved by starting fast with Grails, is already gone because of slow test time. If I could have a single wish for Grails, it would be to abandon the mess of active record. Repositories are just so much more test-friendly.

    38. Roberto Guerra

      @Rodrigo

      ” I don’t think it is a web framework’s concern to talk to databases. That’s what I use Sequel for. They’re separate concerns, and I’m able to test my database access without relying on Rails at all”

      Amen brother.

    39. Does anybody listen about mybatis ? It’s datamapper for sql dbs. It’s one of the best implementation of datamapper pattern I ever seen.There in grails exist grails mybatis plugin but it’s half backed, doesn’t allow annotations.., and it looks that it’s not maintained. @Rodrigo also notice datamapper in Rails world. A lot of people don’t like gorm, or hibernate stuffs(sessions etc..). So why grails core don’t make some grails mybatis plugin ???

    40. @Boris The core team can’t do everything. It’s up to the community to take responsibility for some of this stuff.

    41. @Peter I aggre with you, but persistence layer is so important, that stuff like this should be supported by core team. When they support nosql plugin where nosql have maybe up to 10% of market where 90% is relation DBs. NoSQL hype will be some time, there are some cases where is good to use it. I also using SQL with nosql(as cache layer,session store) but allways SQL is core of majority application. Mybatis is time tested and certainly one of the best(maybe best) implementation of Datamapper for now. I think grails shouldn’t be full copy of rails for jvm, they could also innovate, and innovation in persistence layer could be best way, because DB layer is majority, most important tasks all dbs webapps.

      Also when grails want to be in market classical mvc webapp, so improvement in resources plugin is needed. It’s needed something like asset pipelines in rails, where all static assets are compiled into one file, it’s really awesome for UX.

    42. Hi @Boris, I’m aware of the datamapper gem. It just happens that I prefer the Active Record pattern, which Sequel implements in a better way in my opinion.

      But this is not the reason I don’t like GORM. I just feel there are so many bad defaults and decisions and I just don’t like the way it works. For instance, how could I use a GORM class from a regular Groovy application outside Grails? Since all injection is made by the framework this is not an easy task.

      Compare it to the popular ActiveRecord framework in Ruby:

      class MyModel < ActiveRecord::Base
      end

      As you can see, it inherits most methods from ActiveRecord::Base without any magic injected methods. The exceptions are the accessors based on the table's column names which are created once during iniatialization of the class through some Ruby hook for when a class inherits from another.

      This is much less magical in my opinion and allows us to use those frameworks in any regular Ruby application. This is also valid for all other ORM solutions I know about, not just in Ruby. But it isn't the case for GORM.

    43. I really like GORM for the most part. Maybe my expectations are low due to db wrangling in the java land. That said, it desparately needs a configuration API like hibernate has. People have eluded to this somewhat, but a clean api that only depended on Hibernate which mirrors Hibernate’s own configuration API would solve a lot of problems. I know Spring is really embedded in there, in some cases adding more helpful features, but do I need them for a quick and dirty unit test, or a simple batch script? Let me easily bootstrap GORM with 90% of its features and I will be really happy.

    44. Please have a better documentation.
      All the books are 2 years old and the official doc is not intuitive enough.
      That’s the most important part for the OpenSource Project.

    45. [...] già condiviso il post di Peter Ledbrook dal titolo Where next for Grails? e ora vi propongodue interessanti post di risposta, uno da parte di David Dawson e un altro [...]

    46. [...] linked to Peter Ledbrook’s Where next for Grails? post previously and there have been two interesting followup posts, one from David Dawson and one [...]

    47. Roberto Guerra

      Waking up this thread again after I read a really good blog post about models vs ORM models: http://hynek.me/articles/know-your-models/

      It is referring to Django & Pyramid but it also applies to Grails & Rails. I blame rails for this. Most modern frameworks copied rails, including its bad things. But at least in Rails, there is ActiveModel, which is just an interface that gives you the ability to abstract out ActiveRecord, and hence the persistence concerns out of the domain model. Something that is impossible to do in GORM. I would appreciate if someone could prove me wrong.

    48. @Roberto GORM is an API that has several implementations (witness GORM for MongoDB and the forthcoming GORM for REST). It is still a persistence-related API, but so is ActiveRecord isn’t it?

    49. @Roberto I would tend to disagree with fast/quick development time. Grails still is not widely adopted and their are not alot of developers out there but there ARE alot of shops that want to pick up Grails. Currently the biggest issue with adoption is finding developers and the only way you can get developers to adopt it is to increase interest.

      I think the best way is easy and fast development until you reach a peak mindshare (ie ‘the ruby approach’) and Grails still hasn’t hit that yet as it is battling the Java community which is fighting against itself.

      For years alot of web developers have wanted to switch to Java for web development but found it to verbose, heavy handed and that there were to many components to learn for web development. Grails really brought that down to earth and has the ability to make Java/Grails the defacto MVC platform for the web. Making it more complex ups the entry point and pushes more people out when the framework is still trying to grow its base.

    50. Hi,
      In our company we were using grails for web presentation of some “enterprise” projects and we ended up abandoning it for the very same reasons which are mentioned in comments above again and again.

      If this article would have been written 2 years ago, I would have written the same comment as Rodrigo did now.

      But to summary my view on this:
      - please put an effort to make core and plugins more stable (=bugfree). I see new bugs popping up in already working parts of the framework from version to version. Maybe more rigid review process or coverage requirements would help.
      - I totally agree that Grails should go “beyond Grails” (grails as a platform instead grails as a monolithic RAD – even Rails have done this as I see the comments above; but being modular is even more inherent in java universe)
      - just kill the old build system. Break it, press it, trash it. I think people are just waiting to see if you guys will go for patching the old build system and providing some half baked solution (as seen in last years), or just break it (despite how cruel that would be to all parts) and move on to gradle. The second option would reinforce the people’s trust in you being serious about grails’ viability in the future. This is closely connected to the point above.
      - I also agree that features such as async io will be quickly forgotten if people can deliver business value two-fold faster with classic style. These kind of things are niche and people who really need it will create their own more powerful frameworks. Others just do the stuff normal way 2times faster (development timewise).
      - yep, reloading
      - yep, single page apps support & focus on client (resources etc)
      - yep, powerful customizable scaffolding
      - maybe do a survey to find out where grails is used, how, what for and what changes are necessary for further adoption (some might say for not abandoning it…)

      Thanks a lot for all your effort and I wish you great deal of en energy and patience to move Grails to the next step.
      Juraj

    51. Roberto Guerra

      @Peter, yes ActiveRecord is persistence. And I’m fine with GORM being a persistence API, but my problem is that it bleeds right through the domain model. I would have preferred an adoption of the Datamapper pattern over the Active Record Pattern for GORM.

    52. Wow..the comments are pretty depressing :-P

      I’d say priorities would be:
      - stability
      - small core and plugins for everything (20MB for a minimal size is wayyy too big)-:
      - better unit tests
      - gradle for builds
      - async for scaleability (I’d have to disagree that this isn’t important…most people are going to look at stuff like the techempoower benchmarks as a checkbox item and grails is currently slow w/o async…so even if Node.js is single-process, it still goes fast w/ async and is near the top for performance on modern/RESTful/JSON web sites)

    53. I’m late to this discussion, but it’s still interesting. I find myself looking for alternatives to Grails even though it has been my go-to framework for the past few years. I want something lighter weight since most everything I do now has a Javascript-heavy UI that uses a REST backend.

      For Grails to stay relevant it needs:
      - To be more modular: I don’t need templating, GORM, etc. I don’t really need the resources feature since I’m using something like RequireJS. All those extra unused pieces bloat the WAR. I’m lucky to keep my WAR under 30MB.
      - Easily distributable: Frameworks like vert.x with its event bus and actor-like model provide very flexible and powerful ways to distribute your app.
      - Better stability and performance. I still get memory leaks with Tomcat. Tickets like http://jira.grails.org/browse/GRAILS-9525 were opened last year haven’t been touched.
      - Better support for async request handling: Something better than the Servlet async API, please.
      - Polyglot support: Groovy is great, but we have developers who work better in other langauges (e.g. Scala, Javascript, etc).

    54. Sérgio Michels

      I really liked David’s point of view in his post reply.

      To complement his idea, last week there was a conf about JavaScript (BrazilJS) and I saw a presentation about Yeoman – http://yeoman.io/

      I just looked about some concepts of this in the site, but it seems really interesting.

      It have tools for scaffold, build and control dependencies. Nothing much new here, but if you look at the scaffold part it becomes interesting.

      The concept of generating your application based on a model I think that totally applies to Grails and the plugin ecosystem.

      Instead of giving us a lot of binary plugins, let the community build the stack of an application.

      Maybe for fresh Grails dev teams, choosing witch plugins to attach for his application can be hard. Generators can guide them in this task.

      Perhaps we can have a better approach to notify plugins that aren’t up-to-date in the build too. In my list there are plugins that depends on the Grails version, for example:

      Plugins with available updates are listed below:
      ————————————————————-

      tomcat 2.2.3 2.2.5.BUILD-SNAPSHOT
      rest-client-builder 1.0.3 1.0.2
      resources 1.2 1.2.RC2
      release 2.2.1 3.0.0
      hibernate 2.2.3 3.6.10.M6

    55. Where next for Grails? that implies that it has “arrived”. Well it really hasn’t arrived from a productivity and enterprise application development robustness perspective. See the posts above from Marc Palmer and Rodrigo Rosenfeld Rosas for some context. Before moving to the next level, the following issues need to be addressed:

      1. Grails platform stability. There still remain plenty of bugs. See the issues log.
      2. While there are plugins galore, several of them are stale, unsupported and of poor quality. So what’s a developer to do, evaluate each one and see what works? Majority of plugins are written by good intentioned individuals but with limited time at their disposal.

      Instead of adding new features, perhaps the next 6 months (and yes even a year) should be spent on:

      a. Bug fixes in grails
      b. Documentation
      c. Addressing real world use cases (e.g. being able to update Nested domain objects with complex object graphs)
      d. Writing more realistic sample applications
      e. Building a unit-test case battery. Just curious as to what’s the code coverage achieved by Grails current test suite?
      f. Adoption and support of key plugins directly by Pivotal (and not by individuals or by Pivotal employees acting in individual capacity)

      In my 1 year experience with Grails, I always keep wanting to ditch it for the stability of Java + Spring + Hibernate/JPA. However, there’s still something in the wonder and productivity promise of Grails and Groovy that keeps me suckered-in for my after-hours hobby work, despite the loooong hours tracking down plug-in bugs, grails platform issues, lack of documentation and examples. With all this headache, in all honesty I cannot recommend Grails usage in an enterprise setting – I would be fired once any of the many “problems that are obtuse and difficult” (quoting Marc Palmer) would come up. The productivity benefits very quickly dry up and developer angst sets in.

      Moving on to other feature sets, while building on a less than solid foundation, will only lead to bad press and even less adoption. Let’s the get fundamentals solid and then move to where Grails hasn’t gone before :)

      Hope this helps some.

      Grails Fan.

    56. Sergey Orshanskiy

      Well, let me give some feedback on Grails’ adoption. I have 15 years of programming experience, but only 1 year of web programming, so I am somewhat of a beginner in this space. So far, as far as web frameworks are concerned, I only really have experience with Django and now Groovy/Grails.

      Here are some things that make one want to adopt Grails:
      1. The website grails.org does a good job “selling” the framework :)
      2. The Groovy language is fun to learn and to use.
      3. The scaffolding feature does a good job of “selling” the framework, even if it is not particularly useful. However, it gets very confusing once you are trying to create anything slightly nontrivial, and then you realize that you still have to do the work :) Although it did find the auto-generated GSP’s helpful as examples to be studied.
      4. The documentation is decent, though not even close to Django’s.

      Here are the things that make me want to not use Grails:
      1. Both Groovy and especially Grails are terribly slow. That makes learning very slow. Usually I can learn very quickly by making little changes in some sample code and seeing the result. Here the feedback loop is so slow, probably 10 times slower than with python/django, so the learning curve is slowed down considerably.
      2. Lots of mysterious bugs with application reloading. “grails clean”, “grails compile –refresh-dependencies”… At one point I had to manually delete *.class files for DataSource.groovy . I’ve literally spent hours looking for bugs when all I had to do was to rebuild the whole thing.
      3. The need to understand Hibernate and its issues. In general, completely incomprehensible exception messages. Object’s id is null? How is it my problem? I didn’t even specify that the object has to have an id, it’s an implementation detail. If I wanted to deal with this kind of thing, I would be writing in C++.Similarly, I have recently spent several hours trying to connect Grails to a MySQL database, and I ended up writing a Groovy script to test this connection first. It produces those exceptions with literally dozens of pages of stack traces. And yes, the key information is there, if you know where to look.
      4. Lack of decoupling. I want to be able to just write a groovy script accessing GORM. I know, I can kind of do it with “grails run-script”, but it is so terribly slow. I tried to change java path, etc., to at least debug certain things in a separate groovy shell, but every once in a while I still get some weird exceptions — which I don’t get when using a grails console.

      Overall, I think, I’d look into Ruby on Rails ;-)

    57. For me Grails has been that breath of fresh air and the Java community has seemed to be the blocker; I have seen nothing but a lack of vision and clinging to old thinking from old-school Java devs and that Grails/groovy appeals to a new gen of developers looking for a Java for the next wave.

      I actually was a LAMP deve longing for that new wave of Java for the longest time and Groovy / Grails fit it so well.

      My needs really are:

      1. Unit/integration test documentation. This has been a pain in the butt.

      2. Gradle integration documentation for Grails. Want to start using this more and everywhere. I mostly do alot of copying of code and figuring things out as I go but I would love to have a deeper understanding.

      3. It is LONG overdue for a ‘ADVANCED GRAILS’ book. Everyone has the first books and they were awesome but alot of people stopped there because going beyond that took too much. There really needs to be a LARGE advanced volume or couple of volumes to get people beyond the basics. I spent the last few years pouring over code and I still feel like there is so much more to learn. I’m actually happy for that but there are people who aren’t as thrilled and give up alot easier.

      For those PO’d about the API’s, I’ve actually been spending the last 3-4 mopnths doing a massive rewrite of a group of API plugins I have released into one cohesive api toolkit that will be being released in February (https://github.com/orubel/grails-api-toolkit)

      This simplifies API development to the extreme so ANYONE can get started with API development.

      I will also be extending it eventually for API developer interface(hopefully) and integrating authentication methods so you can authenticate however you want.

    58. @Owen Burt Beckwith’s book Programming Grails should be advanced enough as I understand it.

      The API toolkit sounds interesting. Is that orthogonal to the Grails Plugin Platform or does it overlap somewhat?

    59. @Peter No overlap except if the fact it uses grails same functionality for request/response handling.

      There are some things that I improved on from last few API plugins I hav built like

      - adding roles to apis thus requiring them to be secure by default
      - allowing multiple roles to support HEAD, OPTION and one of GET/PUT/POST/DELETE for example
      - roles for hooks on apis
      - roles on apidocs so one dataset can be defined even though the method returns for two different roles; this allows the apidoc to show only the appropriate data for the role.
      - conversion of domain objects on the fly; though this is still bad practice for an api to use domain objects.
      - improved filter
      - improved encoding
      - passing of content type through headers via HATEOAS spec

      … and more. Its a full API toolkit per the name and not just a one-to-one mapping of api calls to domains as per in Grails. This is meant as a full API support toolkit.

    60. @Peter Oh actually I think I misunderstood your question. Yes overlap in the fact that it EXTENDS the functionality. It uses Grails existing functionality and extends.

      Grails new API functionality is good but it is still mapping domains with CRUD and has direct one-to-one relationship with domains.

      In building api’s, you will often have to do joins in your methods (sometimes across databases) and serve that as your api so you will build a commndobject to validate. What I attempt to do is work not just with one domain but multiple and allow apidoc mapping as well as realtime notifications (webhooks) and integrate all of this with Spring security so your api’s are secured, your hook/callbacks are secured, your apidocs show only to who they are supposed to show, etc.

      And they work with a one lined annotation through your method rather than through the domain so you are mapping the output which is effectively which is what we need to do to take into account all possible solution since a by-the-book RESTful solution doesn’t take into account all possible solutions and is CRUD based; we need to also take into account ‘naming conventions’ that dont comply with the REST naming style but allow them to use REST calls as well.

      Stuff like that. Am really trying to work with all three approaches of RPC, REST and HATEOAS to hit a common api approach which will hit a 90% mark and be accomodating for the rest.

    61. The one thing I would promote (and promote hard) is an abstraction of the API from the model and moving it more towards the ‘front controller’ so you can apply rules definitions and roles at an atomic level to the incoming request and outgoing response separate from the processing/validation of the model data.

      This allows us to have an api object that can be reused for rules and definitions but also to reject at the front controller where rules are not met (separate from validation of the model) and even process separate data for roles at the response given the same model output.

      This also enables api chaining, the api objects to reference each other at the front controller, obfuscation of keys and several other functionality.

      We need to stop think of the URI being associated with the model and the URI being associated with an api object which can associate with a variety of different types of models (ORM, Command Object, etc) thus privilege checking, definitions, rules can be placed prior to continuing on toward processing in the model.

    Leave a reply