GSP Support

[Sabst]

To migrate existing Grails apps away from the monolith or for those who like GSPs, they should be one of the default Server Side View Rendering options.

In the meantime, it would be nice to have an example of how to add this support (apparently using ViewsRenderer...)

[aadrian]

GSP Support would be great!

Maybe it would also allow some of the Grails plug-ins to be easier ported to Micronaut!

[kevintanhongann]

Gotta upvote this.

[Sabst]

I am not changing my mind and still support the initial request :) but for information, even if I would have loved to use GSPs (from a page design and migration standpoint), I failed to use them in my micronaut project (if I remember well, the template engine was hard to isolate). I moved on and evaluated a number of other alternatives I did not know at the time.

I finally used Thymeleaf and, after some hacking, I could for example store templates and views in the DB of my dedicated micro-service and then ask, after providing the variable values, for a rendering of the whole thing.

[codeconsole]

I believe the intention was to get this done back in 2020, but maybe it is not even realistic at this point?
https://grails.org/blog/2020-09-10-grails-state-of-union.html

I am not sure why there is so much hate on monolith apps. Grails still works great and is very scalable if the application is designed right. A well designed monolith app is a lot easier to maintain than a bunch of individual services. I've seen millions of dollars in maintenance costs wasted on micro service coding.

I am not saying that there is no need for micro services as there is always a need to offload certain cpu intensive tasks, but micro services should supplement/not replace monolith apps. I would even go so far as to argue 95% of apps are probably best suited to be monoliths.

[sdelamo]

I love monoliths. I love building monoliths with Micronaut Framework. However, GSP is still coupled to Grails. Thus, we cannot plug it to Micronaut Views yet.

[codeconsole]

@sdelamo Unfortunately, it appears the only people capable of decoupling it are those that are working on Micronaut. It seems like all the development resources went from Grails to creating Micronaut without any pathway for the existing user base to migrate to the new framework. You even have commits to grails-gsp.

Thus my hesitation in using Micronaut on any of my larger projects due to the fear of something similar happening in the future. Don't get me wrong. I love the conciseness and simplicity of Micronaut. I am more than impressed how well it has been designed so far, but it appears Grails has been left in shambles as I am still scratching my head has happened since the 2020 State of the Union.

Coincidentally, everyone that has modified this issue has worked on grails-gsp:
@jameskleeh
@ilopmar
@sdelamo

[gsartori]

@sdelamo I love the work you're doing on Micronaut and I understand the need for resources on such a project. But Grails is still relevant to us (and I guess to a lot of companies that don't need/require microservices) since Grails is a cost-saver technology and if not THE best web framework is with the cool guys for sure. I completely agree with @codeconsole, there is still, and probably will always be, need for monolith apps.

[sdelamo]

@gsartori I love monolith apps and I like GSP.

@codeconsole

It appears the only people capable of decoupling it are those that are working on Micronaut.

Anyone can contribute to Grails or GSP. It does not have to be any past committer.

Micronaut framework offers many server side rendering engines: Thymeleaf, freemaker, apache velocity, rocker, soy, pebble, jte and great features such as the Turbo integration for monoliths.

To set expectations: We don't plan to work on decoupling GSP from Grails and updating it to Groovy 4 (both steps would be required to use in Micronaut Framework) in the next cycles. That said, I will pass your feedback to our technology advisory board.

Moreover, both Grails and Micronaut offer commercial support. If your companies want to fund the migration of GSP to Groovy 4 and its decoupling from Grails and integration into Micronaut Views, it is a perfect use case for commercial support.

[sdelamo]

Another thing to consider is that many Grails + GSP applications leverage open-session-in-view, which we don't support by design in Micronaut Framework. Thus, even with a GSP support in Micronaut Views. Migrating the views layers of Grails app to Micronaut Framework would require significant work.

[erikpragt-connectid]

Hi @sdelamo , you mention that there's no open-session-in-view functionality in Micronaut, which is by design. Is there any documentation on this? I'm failing to find anything related to this, and I'm currently dealing with some lazy loading issues, which surprised me.

[aadrian]

@sdelamo
Having done quite a few projects: from a usability point of view, GSPs are waay better and more productive than the existing MN Views :).

To set expectations: We don't plan to work on decoupling GSP from Grails and updating it to Groovy 4 (both steps would be required to use in Micronaut Framework) in the next cycles.

Sorry but it sounds really strange hearing the above now :( .

The community was living with the impression that this was exactly the promissed plan: step by step to replace Spring Boot parts with MN for Grails, so that later on, Grails would be just a set of extra plug-ins/modules on top of MN.

[codeconsole]

@sdelamo Thymeleaf, freemaker, apache velocity, rocker, soy, pebble, jte are just not viable options coming from Grails. None of them are exciting to use and the syntax is just so far from the simplicity of gsp. They are just way too different and not an easy transition. Nobody wants to transition to something new that could just as easily be abandoned by the same developers promoting what is new.

Literally everyone behind micronaut worked on gsp at some point. Things like open-session-in-view can simply just be stubbed and not supported. I don't think everyone is looking for full Grails GSP capabilities out the gate.

I've already committed to decoupling sitemesh from GSP and I am even willing to assist in adapting it to Micronaut, but I could realty use the support from the pioneers of GSP at the very least to provide an up to date Grails Boot implementation that separates GSP from Grails.

Once that is done, I am willing to take on updating it to Groovy 4 and also get it working with SiteMesh 3. I can even do the SiteMesh 3 micronaut implementation.

[sdelamo]

I have created an issue in GSP Github Issues to decouple GSP from Grails.

@codeconsole If you are interested in working on that issue, please chime in that issue.

Micronaut and Grails Foundations have commercial support offerings. Companies can use commercial support hours to prioritize features and issues.

Moreover, I asked the Micronaut Technology Advisory Board (TAB) in July whether we should invest in decoupling GSP from Grails and upgrading GSP to Groovy 4. The TAB did not consider it a priority.

In the future, we may change this decision. I appreciate the feedback.

[olavgg]

I also think GSP's are great, it has been fantastic together with Grails. GSP templates, makes it possible to use Micronaut for building web applications and not only web services. I dont have to mental capacity for working with multiple micro services and watching json messages being passed between them.

[sdelamo]

@olavgg you can build web applications. We support rendering HTML on the server-side. We support template engines such as Thymleaf, Handlebars, Velocity, Freemarker, Rocker, Soy, Pebble, JTE and Stachio.

[rainboyan]

I don't think it's difficult for Grails to support these templating engines as well, and I've modified the Grails source code to do the same thing as Spring MVC.

[rainboyan]

I don't think the Micronaut team is giving Grails more new features to integrate with Micronaut, which is causing confusion and duplication. I've recently removed Micronaut from Grails, including no longer using Micronaut as the parent application context, and using Spring Boot would be more appropriate to reuse other Spring frameworks and libraries.

[sdelamo]

I don't think the Micronaut team is giving Grails more new features to integrate with Micronaut, which is causing confusion and duplication.

I don't understand what you mean by this.

[rainboyan]

Why Micronaut need GSP? Why migrate your Grails project to Micronaut instead of choosing Spring Boot? GSP integration with Micronaut will lose its dynamic advantage，rather than spending time doing this, continue to enhance and optimize GSP in Grails.

[sdelamo]

You can use groovy and its dynamic capabilities in Micronaut applications.

[rainboyan]

Grails provides core APIs like TagLib, ClassInjector, TraitInjector that make GSP powerful and dynamic, and I don't think that's Micronaut's strength, but Grails can optimize GSP at compile time.