6 ms·

No, you won't. People who gripe about spring didn't bother to do things the spring way. If you wrote your own DAL, you did it wrong. JpaRepositories and the lik

No, you won't. People who gripe about spring didn't bother to do things the spring way. If you wrote your own DAL, you did it wrong. JpaRepositories and the like are the way. If you wrote your own JSON serializer/deserializer you did it wrong, Spring includes Jackson and will do it for you (YMMV). If you rolled your own authentication, you did it wrong. Spring Security can magically lock down your app with as little as a single configuration method, providing jwt/oauth/openid-connect enterprise security out of the box. The issue with spring boot is not it's feature-set or it's robustness. It's with it's heavy handedness to force you down the "spring way". Annotation driven. Extending provided interfaces. Making it "sticky" and impossible to remove. Want to introduce gRPC? yeah, you're going to have to find a way to weave that into Netty or use a different port. It's robust enough just up unto a point where you hit a roadblock and have to dig deep deep into Spring land to understand whats going on. It's still the best framework for standard crud web api's and such with Java. Though micronauts is quickly approaching. You can't go wrong choosing spring boot in 2023 if your intention is to ship in 2024. Whether or not that codebase is solid in 2027 is another matter.

yAak 3y ago
Sorta random, but I really appreciate this kind of post on HN. People have tons of domain expertise and hard-earned lessons that get shared like this, and it broadens my awareness without requiring any time investment on my part. Thank you, thank you (and others like you) for taking the time to type this up!
- gabereiser 3y ago
  I’m shocked actually that you don’t get this kind of mentorship where you work. What’s your Director doing? Not that we’ll be building spring apps but knowing where we, as an industry, have came from and tried things, we’ll avoid them in the future. My heart sinks when a good idea on paper, but bad IRL, get reimplemented 10 years later because someone didn’t bother to read history. That said, sometimes time is all you need for tech to catch up. Rarely that’s the case though. So yeah, you’re welcome, thanks for coming to my grey beard tech talk. Ask your managers for more brown bag/lunch & learns from the older folks at your company - they have stories.
  - guilherme-puida 3y ago
    > I’m shocked actually that you don’t get this kind of mentorship where you work. What’s your Director doing? Bold of you to assume that every company has a technically competent director (or that higher-ups even care about mentorship).
    - gabereiser 3y ago
      I’m sorry. Really. You should be valued enough to warrant skilling up. Future road maps depend on it.
sorokod 3y ago
Annotations are great until something breaks. Fundamentally they are an abstraction over a rats nest of code (of a specific version), library dependencies and configuration. Gods help you when something breaks, the abstraction leaks and you are presented with a glimpse of the underlying complexity that is now yours to tinker with.
- reactordev 3y ago
  Oh don’t get me started when competing data source beans are defined. Which one will @Repository pick up? Which one will it use at runtime? Why is my stack trace 245 deep?
whartung 3y ago
I can't speak to Spring, and I've never worked with it directly. I'm from the Java/Jakarta EE parallel universe. Where everything is the same, but different. Both universes have impacted each other is various ways. JEE has a lot of baggage and notoriety, but, to be fair, so does Spring as they both came up in the same domain at the same time. The XML Hell that JEE was notorious for afflicted Spring as well back in the day. Spring has been more nimble and brought many things to light before they hit the JEE standard, but JEE marches to a different drummer. Modern JEE is pretty darn good. JAX-RS for web services is really nice, and there's a lot of different deployment options. A lot of the things you can love in Spring you can find in JEE, a lot of the things you can hate in JEE you can find in Spring. Again, not able to speak to Spring, but JEE has been really stable over time. In that old code continues to work even in new containers. There's a good chance that could even deploy an old, creaky "J2EE" application from 20 years ago in a modern container. The most disruptive thing to happen to JEE was the Jakartatization of it when it moved from Java EE to Jakarata EE, and all of the namespace changes that happened between Java EE 8 and Jakarta EE 9 with the move from Oracle to Eclipse. But even then, you can still deploy old code in new containers. This was far less disruptive than it could have been, frankly. I'm certainly not going to suggest to not use Spring, but at the same time, I wouldn't discard JEE out of hand either. It's also an exciting space (for assorted values of "exciting" and "enterprise") for back end work.
- TedDoesntTalk 3y ago
  > There's a good chance that could even deploy an old, creaky "J2EE" application from 20 years ago in a modern container. Just no. No. All the different types of EJBs… won’t work. Neither will SOAP endpoints. And a shit ton of other stuff that JEE dropped. What are you talking about? Even XML parsing moved packages.
  - gabereiser 3y ago
    He must still be stuck on JBoss at work…
- mrbonner 3y ago
  Spring was the reason J2EE is better today. It is the reason for existence of Interface21 if you can remember. I think your bad thoughts are tied to the J2EE monster and dumpster fire that goes with it.
zapnuk 3y ago
Sometimes the spring way is also just ugly, or confusing if you just want to do thing X. This code here is used for making HTTP requests using OAuth2. There are probably other ways to do it but I've seen this code in more than one place. I speculate that most people didn't knew they had to use a "AuthorizedClientServiceOAuth2AuthorizedClientManager", but rather found an implementation online and copied it. But as you pointed out, since there are established spring ways to do something, it doen't matter if it's ugly since it actually "just works". ``` @Bean public AuthorizedClientServiceOAuth2AuthorizedClientManager authorizedClientServiceAndManager ( ClientRegistrationRepository clientRegistrationRepository, OAuth2AuthorizedClientService authorizedClientService) { OAuth2AuthorizedClientProvider authorizedClientProvider = OAuth2AuthorizedClientProviderBuilder.builder() .clientCredentials() .build(); AuthorizedClientServiceOAuth2AuthorizedClientManager authorizedClientManager = new AuthorizedClientServiceOAuth2AuthorizedClientManager( clientRegistrationRepository, authorizedClientService); authorizedClientManager.setAuthorizedClientProvider(authorizedClientProvider); return authorizedClientManager; } ```
- vbezhenar 3y ago
  Now make it with user-configurable credentials (like extracted from database) with proper token caching. With similar code I almost made a vulnerability in my app because Spring cached tokens which belong to different users. Spring security is terrible piece of code. Spring - I can stand it. Spring Security - I can not. It was different project back in the day (Acegi Security if I remember correctly). It should have stayed that way.
  - zapnuk 3y ago
    This already uses user-configurable credentials. It uses an autowired "ClientRegistrationRepository" that provides the credentials. We load the credentials once from AWS SecretsManager but I'm sure you could also load them from some DB. But yes, I'd probably prefern a modern rewrite of Spring Security.
  - sverhagen 3y ago
seadan83 3y ago
Spring DAL is really debatable. My view of it is that it is one of those 'fast early development' at the expense of maintenance. It's easy to write code, modifying it later is difficult. Thus I feel this is an optimization to make writing easy code even easier. Therefore the pain of the Spring DAL is unexpectedly slow queries that are doing N+1 selects, having to translate SQL to JPA queries and back [+], dealing with the ORM issue that Spring models database rows and not database results, selects that retrieve far more data than they need, and the unnecessary situation of having to build a full object model to represent database (which is often unnecessary! If my only query aggregates 4 tables and returns two string values, there should be no need to model those 4 tables as full blown Java objects - I'm clearly a fan of things like MyBatis or JDBI for replacing the Spring DAL access. I've been embarking on that very effort at my job, so far replacing Spring JPA to JDBI has reduced a ton of code, was able to recently remove net 40 classes by replacing JPA with JDBI). For example, some queries are naturally best done as analytic queries (or window queries). I have no idea how to do that in JQL (JPA's query language). Moving those queries to the database side can come to the rescure, but it's still an issue.. Which makes me think that JPA makes the easy queries even easier, but the difficult queries nearly impossible (if not outright impossible). > Though micronauts is quickly approaching. I've been looking at micronaut quite a bit as well. Another big downside to springboot is that by default it wants around 100MB of RAM per instance. With 6~7 applications on one host, the expenditure for the memory is sizable. Micronaut has a significant leg up here. [+] DB Queries are often developed first by figuring out what the right query is. After that is done, it needs to be translated to JPA. If JPA eventually starts doing the wrong thing, or something slow - it then needs to be converted to SQL so you can do an explain plan. The latter is not that hard as you can enable a debug output to see what it is, but overall there are quite a few more steps here compared to: "develop your SQL query, next plop that into a string variable in your java code", vs "develop your SQL query, model the table relationships as java objects, build a JPA repository to run some queries against those tables" (in the happy case the latter is all that you need and is not bad, but when a query starts going slow, or starts fetching MB of data which you won't notice on local development but in production causes a p0...)
- eweise 3y ago
  Spring DAL is geared towards operational data stores where typically you are not joining four different tables. Its been a while but pretty sure you can just write the native SQL and map the results to a collection, bypassing mapping to objects. The best strategy I've found is to make the domain objects one-to-one with the tables so their is no joining or inheritance. Do any combining within the repository or application layers. This makes the DAL super simple.
no_wizard 3y ago
What about something like ktor[0]? This looks promising to me, at least. [0]: https://ktor.io/docs/welcome.html https://ktor.io/docs/welcome.html
- Alupis 3y ago
  ktor is best fit for Kotlin applications. But, much like Play Framework - you can use it with just about any (or any?) JVM language. With that said, Spring Boot will be vastly more mature, have a lot more resources available, bigger community, etc. There's also tons of 3rd party libraries that have support for spring and/or spring boot out of the box - such as resiliance4j, openapi-generators, etc. With that said, Spring/Boot's Kotlin support is really good. The team has clearly put a lot of effort into making Kotlin a first-class language within the Spring ecosystem. For backend work, Kotlin + Spring Boot is amazing.
heisenbit 3y ago
I would agree with most except Spring Security is not so simple due to its power and a number of changes over the releases. Trivial cases are simple to do but anything beyond that requires understanding the beast and that takes real effort. More complex cases are then again relatively easy.
- gabereiser 3y ago
  We experts have to pay our bills somehow… I joke but you’re right. Spring Security works up until a point and when you want to make it do exactly what you want it to, you have to crack it open-override or extend-implement your own class (cough UserDetailService cough). Still, if you’re doing microservices with spring, spring security is enough to ensure your jwt in the request is valid. I like to pair it with more robust auth like Keycloak though if I’m going “platform” instead of monolith.
Tainnor 3y ago
> People who gripe about spring didn't bother to do things the spring way. Of course, everyone who complains about a technology just hasn't learned it properly. I think I understand the Spring model fairly well at this point. But one of the problems with it is that it's confusing and that the runtime-reflection-heavy approach causes issues with debuggability, performance and also errors creeping into production that should by all accounts be preventable at compile-time. It's rather easy to make silly mistakes with Spring, such as confusing @Configuration and @ConfigurationProperties or writing tests that share the application context even though they require different configuration and suddenly stop working if they're executed in the wrong order, and even if you yourself learn it perfectly, your coworkers might not. I agree that it offers a ton of benefits - but that doesn't mean that it isn't valid to criticise it.

yAak 3y ago

Sorta random, but I really appreciate this kind of post on HN. People have tons of domain expertise and hard-earned lessons that get shared like this, and it broadens my awareness without requiring any time investment on my part. Thank you, thank you (and others like you) for taking the time to type this up!

gabereiser 3y ago
I’m shocked actually that you don’t get this kind of mentorship where you work. What’s your Director doing? Not that we’ll be building spring apps but knowing where we, as an industry, have came from and tried things, we’ll avoid them in the future. My heart sinks when a good idea on paper, but bad IRL, get reimplemented 10 years later because someone didn’t bother to read history. That said, sometimes time is all you need for tech to catch up. Rarely that’s the case though. So yeah, you’re welcome, thanks for coming to my grey beard tech talk. Ask your managers for more brown bag/lunch & learns from the older folks at your company - they have stories.
- guilherme-puida 3y ago
  > I’m shocked actually that you don’t get this kind of mentorship where you work. What’s your Director doing? Bold of you to assume that every company has a technically competent director (or that higher-ups even care about mentorship).
  - gabereiser 3y ago
    I’m sorry. Really. You should be valued enough to warrant skilling up. Future road maps depend on it.

sorokod 3y ago

Annotations are great until something breaks. Fundamentally they are an abstraction over a rats nest of code (of a specific version), library dependencies and configuration. Gods help you when something breaks, the abstraction leaks and you are presented with a glimpse of the underlying complexity that is now yours to tinker with.

reactordev 3y ago
Oh don’t get me started when competing data source beans are defined. Which one will @Repository pick up? Which one will it use at runtime? Why is my stack trace 245 deep?

whartung 3y ago

I can't speak to Spring, and I've never worked with it directly. I'm from the Java/Jakarta EE parallel universe. Where everything is the same, but different. Both universes have impacted each other is various ways. JEE has a lot of baggage and notoriety, but, to be fair, so does Spring as they both came up in the same domain at the same time. The XML Hell that JEE was notorious for afflicted Spring as well back in the day. Spring has been more nimble and brought many things to light before they hit the JEE standard, but JEE marches to a different drummer. Modern JEE is pretty darn good. JAX-RS for web services is really nice, and there's a lot of different deployment options. A lot of the things you can love in Spring you can find in JEE, a lot of the things you can hate in JEE you can find in Spring. Again, not able to speak to Spring, but JEE has been really stable over time. In that old code continues to work even in new containers. There's a good chance that could even deploy an old, creaky "J2EE" application from 20 years ago in a modern container. The most disruptive thing to happen to JEE was the Jakartatization of it when it moved from Java EE to Jakarata EE, and all of the namespace changes that happened between Java EE 8 and Jakarta EE 9 with the move from Oracle to Eclipse. But even then, you can still deploy old code in new containers. This was far less disruptive than it could have been, frankly. I'm certainly not going to suggest to not use Spring, but at the same time, I wouldn't discard JEE out of hand either. It's also an exciting space (for assorted values of "exciting" and "enterprise") for back end work.

TedDoesntTalk 3y ago
> There's a good chance that could even deploy an old, creaky "J2EE" application from 20 years ago in a modern container. Just no. No. All the different types of EJBs… won’t work. Neither will SOAP endpoints. And a shit ton of other stuff that JEE dropped. What are you talking about? Even XML parsing moved packages.
- gabereiser 3y ago
  He must still be stuck on JBoss at work…
mrbonner 3y ago
Spring was the reason J2EE is better today. It is the reason for existence of Interface21 if you can remember. I think your bad thoughts are tied to the J2EE monster and dumpster fire that goes with it.

zapnuk 3y ago

Sometimes the spring way is also just ugly, or confusing if you just want to do thing X. This code here is used for making HTTP requests using OAuth2. There are probably other ways to do it but I've seen this code in more than one place. I speculate that most people didn't knew they had to use a "AuthorizedClientServiceOAuth2AuthorizedClientManager", but rather found an implementation online and copied it. But as you pointed out, since there are established spring ways to do something, it doen't matter if it's ugly since it actually "just works". ``` @Bean public AuthorizedClientServiceOAuth2AuthorizedClientManager authorizedClientServiceAndManager ( ClientRegistrationRepository clientRegistrationRepository, OAuth2AuthorizedClientService authorizedClientService) { OAuth2AuthorizedClientProvider authorizedClientProvider = OAuth2AuthorizedClientProviderBuilder.builder() .clientCredentials() .build(); AuthorizedClientServiceOAuth2AuthorizedClientManager authorizedClientManager = new AuthorizedClientServiceOAuth2AuthorizedClientManager( clientRegistrationRepository, authorizedClientService); authorizedClientManager.setAuthorizedClientProvider(authorizedClientProvider); return authorizedClientManager; } ```

vbezhenar 3y ago
Now make it with user-configurable credentials (like extracted from database) with proper token caching. With similar code I almost made a vulnerability in my app because Spring cached tokens which belong to different users. Spring security is terrible piece of code. Spring - I can stand it. Spring Security - I can not. It was different project back in the day (Acegi Security if I remember correctly). It should have stayed that way.
- zapnuk 3y ago
  This already uses user-configurable credentials. It uses an autowired "ClientRegistrationRepository" that provides the credentials. We load the credentials once from AWS SecretsManager but I'm sure you could also load them from some DB. But yes, I'd probably prefern a modern rewrite of Spring Security.
- sverhagen 3y ago

seadan83 3y ago

Spring DAL is really debatable. My view of it is that it is one of those 'fast early development' at the expense of maintenance. It's easy to write code, modifying it later is difficult. Thus I feel this is an optimization to make writing easy code even easier. Therefore the pain of the Spring DAL is unexpectedly slow queries that are doing N+1 selects, having to translate SQL to JPA queries and back [+], dealing with the ORM issue that Spring models database rows and not database results, selects that retrieve far more data than they need, and the unnecessary situation of having to build a full object model to represent database (which is often unnecessary! If my only query aggregates 4 tables and returns two string values, there should be no need to model those 4 tables as full blown Java objects - I'm clearly a fan of things like MyBatis or JDBI for replacing the Spring DAL access. I've been embarking on that very effort at my job, so far replacing Spring JPA to JDBI has reduced a ton of code, was able to recently remove net 40 classes by replacing JPA with JDBI). For example, some queries are naturally best done as analytic queries (or window queries). I have no idea how to do that in JQL (JPA's query language). Moving those queries to the database side can come to the rescure, but it's still an issue.. Which makes me think that JPA makes the easy queries even easier, but the difficult queries nearly impossible (if not outright impossible). > Though micronauts is quickly approaching. I've been looking at micronaut quite a bit as well. Another big downside to springboot is that by default it wants around 100MB of RAM per instance. With 6~7 applications on one host, the expenditure for the memory is sizable. Micronaut has a significant leg up here. [+] DB Queries are often developed first by figuring out what the right query is. After that is done, it needs to be translated to JPA. If JPA eventually starts doing the wrong thing, or something slow - it then needs to be converted to SQL so you can do an explain plan. The latter is not that hard as you can enable a debug output to see what it is, but overall there are quite a few more steps here compared to: "develop your SQL query, next plop that into a string variable in your java code", vs "develop your SQL query, model the table relationships as java objects, build a JPA repository to run some queries against those tables" (in the happy case the latter is all that you need and is not bad, but when a query starts going slow, or starts fetching MB of data which you won't notice on local development but in production causes a p0...)

eweise 3y ago
Spring DAL is geared towards operational data stores where typically you are not joining four different tables. Its been a while but pretty sure you can just write the native SQL and map the results to a collection, bypassing mapping to objects. The best strategy I've found is to make the domain objects one-to-one with the tables so their is no joining or inheritance. Do any combining within the repository or application layers. This makes the DAL super simple.

no_wizard 3y ago

What about something like ktor[0]? This looks promising to me, at least. [0]: https://ktor.io/docs/welcome.html https://ktor.io/docs/welcome.html

Alupis 3y ago
ktor is best fit for Kotlin applications. But, much like Play Framework - you can use it with just about any (or any?) JVM language. With that said, Spring Boot will be vastly more mature, have a lot more resources available, bigger community, etc. There's also tons of 3rd party libraries that have support for spring and/or spring boot out of the box - such as resiliance4j, openapi-generators, etc. With that said, Spring/Boot's Kotlin support is really good. The team has clearly put a lot of effort into making Kotlin a first-class language within the Spring ecosystem. For backend work, Kotlin + Spring Boot is amazing.

heisenbit 3y ago

I would agree with most except Spring Security is not so simple due to its power and a number of changes over the releases. Trivial cases are simple to do but anything beyond that requires understanding the beast and that takes real effort. More complex cases are then again relatively easy.

gabereiser 3y ago
We experts have to pay our bills somehow… I joke but you’re right. Spring Security works up until a point and when you want to make it do exactly what you want it to, you have to crack it open-override or extend-implement your own class (cough UserDetailService cough). Still, if you’re doing microservices with spring, spring security is enough to ensure your jwt in the request is valid. I like to pair it with more robust auth like Keycloak though if I’m going “platform” instead of monolith.

Tainnor 3y ago

> People who gripe about spring didn't bother to do things the spring way. Of course, everyone who complains about a technology just hasn't learned it properly. I think I understand the Spring model fairly well at this point. But one of the problems with it is that it's confusing and that the runtime-reflection-heavy approach causes issues with debuggability, performance and also errors creeping into production that should by all accounts be preventable at compile-time. It's rather easy to make silly mistakes with Spring, such as confusing @Configuration and @ConfigurationProperties or writing tests that share the application context even though they require different configuration and suddenly stop working if they're executed in the wrong order, and even if you yourself learn it perfectly, your coworkers might not. I agree that it offers a ton of benefits - but that doesn't mean that it isn't valid to criticise it.