3 ms·

> Spring has gotten so bloated. I'd call Spring feature-rich than bloated. You can always shed weight that you don't want to carry. > Plus there's multiple wa

> Spring has gotten so bloated. I'd call Spring feature-rich than bloated. You can always shed weight that you don't want to carry. > Plus there's multiple ways of doing the same thing. e.g. JPA, spring-data. That's because there are different ways to solve a problem. Someone may want an ORM-based approach to connect to the database; they can choose spring-data-jpa. Someone may want to use JDBC with a light abstraction on top of it; they can choose spring-data-jdbc. It's all about choices and right tradeoffs and Spring offers plenty of them. > they don't provide easy upgrade paths between majors versions That's not my experience. I've been happily upgrading 2.x.x versions and plan to upgrade to 3.2.x when it is ready. But depending on the codebase, I admit it can be painful. Projects like OpenRewrite[1] might help here. > and they stop updating vulnerabilities on older major versions. This is not news. They want you to pay for extended support if you need it. > No docs on migration. They do maintain migration docs on GitHub wiki which are a lot more detailed than their blog posts on migration. Here's the latest one to upgrade from Spring Boot 2 to 3: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide https://github.com/spring-projects/spring-boot/wiki/Spring-B... [1]: https://github.com/openrewrite/rewrite https://github.com/openrewrite/rewrite

Salgat 3y ago
My biggest issue with "feature rich" is that unless you have strict control over your developers' usage (which won't happen in most large companies), you'll inevitably have all sorts of bloat used by various teams in your organization, which just adds to the cognitive overhead for anyone who needs to work on those services. You know the old adage: once you provide something in the API, you'll have to support it forever.

Salgat 3y ago

My biggest issue with "feature rich" is that unless you have strict control over your developers' usage (which won't happen in most large companies), you'll inevitably have all sorts of bloat used by various teams in your organization, which just adds to the cognitive overhead for anyone who needs to work on those services. You know the old adage: once you provide something in the API, you'll have to support it forever.