Посмотрел видео – https://www.youtube.com/watch?v=d_GHTBqI7YE (Dependency Injection: Refactoring from Spring to Kotlin | Dmitry Kandalov @ Advanced Kotlin Dev Day). Плюс, недавно много работал с NestJS, который так же по ощущениям сильно похож на Spring. Так что захотелось проанализировать.

Что уже не использую?

  • @Cached – плохо реализовано с множеством ограничений, особенно при использовании Kotlin coroutines, проще без него
  • @Async – не нужно из-за Kotlin coroutines

База (много аналогов или аналоги просто сделать):

  • конфигурация из файлов и переменных окружения с профилями (может быть довольно легко заменено на не Spring при необходимости)
  • http-контроллеры (включая конвертеры, openapi и graphql) – тут уже на всех языках и фреймворках примерно одинаково
  • внедрение зависимостей – есть куча альтернатив, можно и явно (как в видео выше)
  • интеграция с healthcheck и prometheus
  • Spring Http Interface Clients – позволяют создавать клиенты к другим сервисам декларативно (есть альтеранативы – refrofit, jax-rs, может еще какие)

Что хорошо?

  • Spring Data Repositories – позволяют добавить декларативности и писать меньше кода (если SQL-база, то только для простых случаев, а для сложны что-то вроде jOOQ).

Что плохо?

  • нативная сборка – это прям боль как по настройке, так и по запуску
  • автонастройка – оно как бы заявлено, но выливается в огромное количество gradle-файлов и классов в пакете config. На других же платформах умудряются обходиться 1-2 небольшими файлами. Это больше к вопросу об адекватных настройках по умолчанию.

Как итог, нет каких-то огромных технических преимуществ Spring перед альтернативами (Quarkus / KTor / …), а у альтернатив есть свои преимущества. Так что постепенно пальма первенства будет утрачена. Основное люди: много программистов знает Spring и/или готово на нем программировать из-за его популярности. Дополнительно: хорошая документация (хотя у того же Quarkus или NestJS лучше, т.к. быстрее позволяет применять), которая описывает как что-то делать в том или ином случае (не нужно заниматься изобретениями на пустом месте как в менее структурированных фреймворках).

Неожиданный вывод: Gradle ужасен (огромное количество файлов, которые сложно переиспользовать из одного проекта в другой и вообще непонятно зачем их писать без наличия особых требований). И Maven не лучше (не зря многие покинули его). Так что есть пространство для новой системы сборки. И/или форка / надстройки.