Another Attempt At Micronaut

Some while ago I started a new project, and I thought this would be a good time to try out Micronaut again. I had some initial problems with setting everything up, but I always found a way around it. Things didn't. go very smooth though, and in this blog post, I will share my experience with Micronaut and the entire ecosystem around it.

An example of the early issues what the new test resources plugin that Micronaut provides. When I added it, it seems to always spin up test resources, even when you run it locally and not just when running tests. I didn't verify if a real build would do the same, but it seems a bit worrisome. Moreover, it causes the integrated test runner in VSCode to fail, which can be worked around by, by delegating the tests to Gradle, but that isn't very handy and for some reason also didn't work for me. By just not using the test-resources and using the regular test dependencies all these issues where fixed, so this wasn't a real blocker.

Micronaut has some interesting approaches and ideas about things, which is why I really want to use it, such as the philosophy of getting rid of reflection. As a result however database interfaces (repositories) need to be annotated with which server you are using, which makes it difficult to switch, but you can create your own annotation, such that you only have to specify it in one spot. DAOs and DTOs also had some requirements on public no args constructors and setters for each field. This makes sense if you think about it, because you need to be able to set all fields, but this means that I had to allow more things than I wanted. It would have been nice if an all args constructor would have been used instead, which maybe can be done somehow, as I didn't really experiment a lot with this.

A bigger problem is the bad integration with VSCode, I had multiple occasions where a restart in debug mode would just hang and I had to restart VSCode to get it to work again, although I suspect this may be more a Gradle issue than Micronaut. Startup time was also rather slow somehow, slower than with my much bigger Spring application. Seems like Micronaut does a lot of work to compile everything again instead of just incremental builds, this may again be caused by Gradle and no by Micronaut. The Micronaut plugin in VSCode also relies on the Netbeans language server instead of the Redhat one (which I have used before and is required by the test runner), so I ended up with both of them installed.

What finally pushed me over the edge was that I couldn't get the exception handling of the controllers to work. I tried having an exception handler in the controller itself, I tried to have a custom handler class, but nothing worked. The latter case was also not ideal, because I would have to make a different handler class for EACH exception. My initial idea was to have them all in a final class like this

private final class ExceptionHandler {

    private class BadRequestHandler {
        ...
    }
}

But I was never able to confirm whether that worked or not. The lack of community, clear documentation and guides is what made me throw in the towel on Micronaut for this project. I still want to try Micronaut in the future, but I will do it with Maven instead of Gradle, and on a project that I don't feel is as essential to quickly mature as the one I am currently working on.

For this project, I went back to Spring with Maven which was a rather easy conversion to do (mainly because the project was still small). Spring just seems to have a much bigger community, much more mature tools and better guides and documentation.