I agree that grails is a bit heavyweight. The people at my former place did some work on using groovy with dropwizard: https://speakerdeck.com/kyleboon/webservices-with-dropwizard... which is seems to be more of a nice collection of libraries, rather than a box you in framework.
Its fine when it works, but expect inscrutable session flushing errors when you try and flex it too hard.
On top of that, you can write your own hibernate xml on which your domain objects depend. If you get too fancy, you'll lose some of your GORM syntactic sugar, but you do have options.
http://stackoverflow.com/questions/425294/sql-database-views... is how you would do direct SQL without GORM, which you would use if you wanted to avoid hibernate entirely. The rest is just command objects - http://grails.org/doc/latest/guide/theWebLayer.html#commandO... - and more importantly, @Validatable. http://grails.org/doc/latest/guide/validation.html#validatio...
(Technically, command objects are a specific function within the controller, but what we're really looking to do is leverage the validation framework.)
It's extra work, but no less so than avoiding an ORM in any framework. But if you can do it in Hibernate, you probably don't need to bother with this most of the time. (When I had to do it, it was to interface with stored procedures.)
http://grails.org/doc/latest/guide/hibernate.html is there if you want to bolt GORM on to legacy classes.
It is trivial to remove the GORM/Hibernate dependencies from Grails.
If you can use No-Sql databases that offer a REST API, all you will need is an additional dependency on Httplib so you can make the calls.
Sql sql = new Sql(dataSource)
List results = sql.rows('SELECT * FROM mytable WHERE type_id = :type_id', [type_id: id])
People that like static languages use Java, Scala, etc.
People that like dynamic languages use Python, Ruby (JRuby), etc.
Who's left over to use Groovy?
The people that like Grails and Gradle. Which is fine, but the popularity of the whole language is resting on these two frameworks, IMO, which seems precarious.
It's original thesis, a scripting language for the JVM, was interesting when it first started, but since then the JVM implementations of traditional scripting languages has gotten really good.
Personally, I believe that if they'd pivoted to static typing around Groovy 1.0, they would have been the Java next by now. They would have won.
They were years ahead of Scala. And it's always sounded like a great, working man's language/compiler, e.g. powerful AST/meta-programming/etc.
There were people in the Groovy camp who wanted to do this (the @Typed annotations that they have now), but it took too long, AFAICT, because the core committers had spent so much time convincing everyone that a dynamic language on the JVM was worthwhile that they didn't realize a static one would have taken their adoption to the next level.
vert.x - http://vertx.io
Spring Boot - http://projects.spring.io/spring-boot/
It's possible to wire up a micro webframework example with only a couple lines of code in Groovy.
Remember that Groovy, Grails, and Spring Boot are run by the same company, there might be some synergy between the latter two at some point.
It's because Groovy and its apps like Grails are part of the same company that many developers are afraid of creating anything web-related for Groovy that's not a Grails plugin.
Grails head Graeme Rocher was evn one of the 5 Groovy despots for 4 yrs, and didn't leave until a few months ago. This could have been what prompted the Play! 2 framework to purge itself of all its Groovy code.
Grails head Graeme Rocher was one of the 5 Groovy despots [1] until a few months ago. He joined the despotry 4 yrs ago, which could have been what prompted the Play! 2 framework to purge itself of all its Groovy code. Groovy really needs its managers to be divorced from those developing the apps that use it, so others will join the ecosystem without being suspicious of what might happen in the future.
Btw, I don't work for any company with a vested interest against Groovy, but am reimplementing Groovy as a side project.
Sounds pretty cool. Looking forward to seeing what you come up with!