I watched the video – https://www.youtube.com/watch?v=d_GHTBqI7YE (Dependency Injection: Refactoring from Spring to Kotlin | Dmitry Kandalov @ Advanced Kotlin Dev Day). Plus, I’ve recently worked a lot with NestJS, which also feels very similar to Spring. So I wanted to analyze it.
What am I not using anymore?
- @Cached – poorly implemented with many limitations, especially when using Kotlin coroutines, easier without it
- @Async – not necessary because of Kotlin coroutines
Base (many analogues or analogues are easy to make):
- configuration of files and environment variables with profiles (can be quite easily replaced with non-Spring if necessary)
- http controllers (including converters, openapi and graphql) – here it is already about the same in all languages and frameworks
- dependency injection – there are a bunch of alternatives, you can do it explicitly (as in the video above)
- integration with healthcheck and Prometheus
- Spring Http Interface Clients – allow you to create clients to other services declaratively (there are alternatives – refrofit, jax-rs, maybe some more)
What’s good?
- Spring Data Repositories – allow you to add declarativeness and write less code (if SQL is a database, then only for simple cases, and for complex ones something like jOOQ).
What’s wrong?
- native build is a real pain both in setup and launch
- auto-tuning – it’s kind of stated, but it results in a huge number of gradle files and classes in the config package. On other platforms, they manage to manage 1-2 small files. This is more about the question of adequate default settings.
As a result, there are no huge technical advantages of Spring over alternatives (Quarkus / KTor / …), but alternatives have their advantages. So gradually the palm tree will be lost. The main thing is people: a lot of programmers know Spring and/or are ready to program on it because of its popularity. Additionally: good documentation (although the same Quarkus or NestJS is better, because it allows you to use it faster), which describes how to do something in one case or another (you do not need to invent inventions from scratch as in less structured frameworks).
An unexpected conclusion: Gradle is terrible (a huge number of files that are difficult to reuse from one project to another, and it is generally unclear why they should be written without special requirements). And Maven is no better (no wonder many left it). So there is space for a new build system. And/or fork/add-ons.