https://grails.org/ logo
Join Slack
Powered by
Folks, is there someone here who can tell what we ...
# questions
g
Folks, is there someone here who can tell what we are missing from Micronaut to be the only root for Grails? What is that Spring has that the latest version of Micronaut doesn't?
j
There is a major design difference between Micronaut & Spring - Micronaut targets a stateless session, while spring allows for either stateful or stateless. For example, in a Spring app you can do things like 
@EnableJdbcHttpSession
and have persisted sessions across different nodes of a cluster. Most of the grails plugins also seem to be spring in origin, so removing spring would break / requiring porting functionality such as: 1. Spring Security 2. Spring Security Rest 3. Quartz 4. Spring Integration / Batch (does this concept even exist in micronaut?) 5. TagLibs 6. Views (https://github.com/micronaut-projects/micronaut-views/issues/5)
👍 2
I'm sure there are others, but that's just off the top of my head
I am not saying it couldn't be done, there's probably equivalent functionality for most of this stuff, but the session would cause the largest migration issue. It would also probably mean that version of grails would be more painful to upgrade to - even more than grails 3 was.
g
Okay, so it would be better to start over and build a "Mrails" like a "Micronaut on Rails" kind of thing if we want to have Micronaut under the hood
If I got it correctly
j
Not sure which is best. Micronaut has primarily targeted micro service architecture, while Spring has historically targeted monoliths and been adapted to support both. A lot of the lessons learned by Micronaut (and for that matter Quarkis) seem to be making their way into spring. Seems like it would be better to enhance micornaut to just support Gorm (with groovy 4) & GSPs and then adapt to that style.
or just use spring only.
Your question seemed to assume that micronaut was the way forward instead of Spring. What drives that decision for you?
g
It's not a decision, is more like an opinion. Because Micronaut was added to Grails, and the only reason my small brain can think of for that move was to migrate to Micronaut.
j
That's exactly why there's thought that it should just be removed since it's never been adopted / used further: https://github.com/orgs/grails/discussions/13517
All of the grials controllers are spring controllers, not micronaut controllers. Also, the beans in grails are really spring beans first, so the micronaut context configuration isn't even consistent - if you use 
@Value
to inject configuration and that configuration was in spring, then micronaut won't see it. It's really an after thought and a maintenance burden.
g
Yep I am one of those that voted to remove Micronaut. I was curious though
j
There's also https://micronaut-projects.github.io/micronaut-spring/latest/guide/ which means you can still use micronaut if you want, the frameowrk just doesn't have to support it.
So it seems to be a no brainer to remove it, and then if you need that functionality use that plugin
g
I agree 100% on the removal, but I have to feed the monkey in my brain, she's curious 🙂
g
If maintaining MicroNaut is a liability, definitely it should be removed. Grails need to be way more light weighted.
2 Views
Open in Slack
PreviousNext
Powered by