Did anyone try this with Kotlin? What are performances? I know it is possible I was wondering about experiences and whether it is worth it - to switch to using Grails and Kotlin instead of Spring and Kotlin.
I learned SpringBoot before joining a team that primarily works with Grails using Groovy. I never tried using Kotlin with Grails myself.
In my opinion, Groovy fits Grails well. They’re both implicit in many ways. Unlike Spring’s odd “programming with method names” here and there, Grails takes it up several notches of hidden convention and implicit association. Things gets detached from its clear meaning.
I think a lot of this user pain stems from a overuse of “convention over configuration”. In Grails, just like in Groovy and other difficult to tool languages, it’s difficult to trace a value through the framework since you need custom tools in order to see the docs or jump between bean mapping.
IntelliJ Ultimate has great tooling for both Spring and Grails to the point that almost entirely eliminates my frustrations with the framework. It’s paid. If Grails relied on less hidden conventions then you would get all the same tooling for free from the language.
Kotlin could fix most of the issues that spread through Groovy libraries in a Grails project. But personally I would prefer to use the standard directory layout (Grails makes you change that*), and use the newer Spring Kotlin support that they have been working for over the last couple years.
Grails is good in a lot of ways, it’s a powerful framework. But I’d personally choose SpringBoot over Grails even if Kotlin wasn’t in the picture. My colleagues who are the main reason we use Grails are trying to move away from Grails to Micronaut (made by the same people who did Grails).
It’s a long time since I’ve used Grails, so my experience might be outdated. But I remember a framework with
a lot of incomprehensible magic (above the already pretty complex frameworks Spring and Hibernate)
a strange and sometimes hard to debug language (Groovy). Even if you use it with Kotlin, you will build your code on a Groovy foundation.
a silly DSL much more error-prone than annotations (see GORM, validation for example)
limited routing capabilities
weak REST support
stringly typing everywhere
strange shortcuts like merging the “repository” into an entity class (the entity class has persistence methods).
All in all I think Grails focuses way too much on a superficial API beauty that doesn’t help much and make things worse if you do more than small projects. However the scaffolding is impressive, but not that useful in the long run. In the end I replaced almost everything generated by the framework.
Maybe Grails is better today, but I doubt they changed course in a fundamental way. I wouldn’t use it again.
I would recommend Spring Boot. Quarkus and Ktor are looking promising, but I haven’t used them for more than a “hello world”.
This is a very detailed answer and thank you so much for that it has been my hunch as well that Spring Boot with Kotlin is filling the need quite well. Specially with latest integration of Kotlinx coroutines with WebFlux.
Although the integration between WebFlux and Coroutines might be good, I would think twice if it wouldn’t be better to use Reactor that is used in the rest of the Spring framework and is a really powerful tool.
Yea I mean Reactor is of course library of choice for Spring WebFlux so it makes more sense to use it if you really want performance improvement but with Coroutines you have lighter API and much better readability.
Has anyone ever compared Reactor vs Coroutines with WebFlux? (I guess coroutines rely on Reactor in Spring?)
What do you mean with “lighter API”? Coroutines alone are not a replacement for Reactor. If you want to compare the both, you would better compare Reactor with Kotlin Flow. The latter has a “lighter” API because it has not nearly as many operators, but the operators make Reactor so powerful. I’d argue that typical processing logic with filter, map etc. would pretty much the same. The main difference would be subscription (consumption of the results), using schedulers, and error handling, but that is not what makes development hard.
However, I don’t want to say that async programming with Reactor would be easy. It takes some time to get used to it. But I’d say the same is true for coroutines and Flow.
Even if you want to use Kotlin in Grails you have to write Controllers in Groovy. The rest may be Kotlin or Java or mix.
Also Micronauts includes first class support for all Groovy, Java and Kotlin. This would be the way to go unless you need a big app. container like Tomcat.
Wow. I just saw this. I’m the creator of Beapi Api Framework. So pleased this is getting mentioned in other language forums. Yeah I put alot of work into this such as profilers, automated api docs, automated batching, automated webhooks, auto caching, rate limiting, JWT token management, etc etc
And we are constantly adding on to simplify your developer experience and reduce your workload.
For those currently using it, we always look forward to your feedback. For those who aren’t, we ask you try it out and give us your feedback to; we are always looking for negative feedback from new users as it helps us to improve our product and new users (especially from different languages) helps us to improve our offering.
well speaking as the creator of Beapi, the ‘weak REST support’ is mainly due to the fact that people in the community like me build VERY CAPABLE full featured plugins that automate nearly ALL of it to avoid people who don’t understand API’s making common pitfalls of mistaking REST for RESTFUL for RPC etc etc. and things of that nature.
The features you talk about are all supplied by plugins.
