Spring-rs is a microservice framework in Rust inspired by Java's spring-boot

(github.com)

Show context

npstr ◴[17 Aug 24 23:52 UTC] No.41279021[source]▶

I can see a lot of hate in the comments about the original Spring Project / Java language. You are absolutely right, it's the worst. Please go away, nothing to see there =)

On a different note though, when I was a Junior, building my first few projects, I didn't get it either. You'll get it when you make it to true Senior level :) Just last year I took over a project at work where 2-4 engineers (including "Senior"s, especially the one who came up with the infrastructure) were very busy reinventing their own framework/platform instead of building the actual product, for about 3 years. They had their own protocols and their own transaction management and two webservers (cause they were trying to use VertX websockets in addition to HTTP but due to a skill issue couldn't serve them from a single webserver) etc etc. What they did not have, was a working product. I got buy-in from management up to C level to rewrite that burning garbage dump. Now, about a year later, after management moved those people off and me in, the product is actually live with all the missing features, has about 50% less LoC than at its peak, and does no longer exist as a distributed stateful microservice agglomeration. Instead it's a Spring Boot monolith. Including Spring Security. It was the first time any of my software got a security bug found by external researchers and only because I did not add Spring Security immediately along Spring Boot because I thought we can go along with the homegrown auth code for a while longer.

Anyways, serious people who have built some serious (web) products will appreciate the battle proven tech that has integrations with just about any other relevant software on the planet and implements production ready patterns for you to immediately use.

If you don't, may I suggest you ask yourself: maybe you've just been building only toy projects, or solving too much leet code problems? Maybe you've only worked on projects meant for your resume or promotion dossier, rather than actually putting a product live to millions of users?

I applaud the Rust ecosystem taking one of the best pages from the Java ecosystem book, although the focus on "lightweight" does not make me optimistic that the author has truly understood what value, and how, Spring delivers.

replies(6): >>41279363 #>>41279489 #>>41279766 #>>41280266 #>>41281059 #>>41282389 #

1. tonyarkles ◴[18 Aug 24 01:09 UTC] No.41279363[source]▶

>>41279021 #

Heh, my personal complaint about Spring comes from the other side of this. I came into a company where Spring Boot was already deeply entrenched, in a Senior DevOps/Sysadmin type of role. I spent a significant amount of time untangling all of the voodoo reflection magic that the teams who had created the services couldn't seem to debug on their own.

To be fair to Spring Boot, the developers in question didn't have any real operations mentality, which complicated things. A service would crash/500 and would have a 0-byte log file documenting everything that led to the crash. It was pretty surpassing though to discover that a lot of the visibility things I'd come to expect from the large variety of other non-Java frameworks didn't seem to be included by default (eg request logging/exception logging) and had to be turned on explicitly.

replies(1): >>41279963 #

2. re-thc ◴[18 Aug 24 03:37 UTC] No.41279963[source]▶

>>41279363 (TP) #

> Heh, my personal complaint about Spring comes from the other side of this.

What did your example have to do with Spring? It sounds like it'd have been the same if replaced with something else. It was the developers...

replies(2): >>41281745 #>>41282040 #

3. tonyarkles ◴[18 Aug 24 11:45 UTC] No.41281745[source]▶

>>41279963 #

Mostly that the whole annotation-based dependency injection part can be a mess to debug and that it seemed to (at the time, unsure about the present) have very odd defaults around logging.

The annotation-based DI seemed to do a really good job of turning what should have been a compile-time error into a runtime exception instead.

replies(1): >>41281873 #

4. re-thc ◴[18 Aug 24 12:12 UTC] No.41281873{3}[source]▶

>>41281745 #

> Mostly that the whole annotation-based dependency injection part

Right, but DI isn't Spring specific, so point still holds.

Within Java there are plenty of other annotation frameworks...

In other languages there are annotation usages and sometimes EVEN worse behavior exists...

And yet for reasons I'd like to know people aren't blaming those (at least not in the same capacity). That's the crux of the issue.

replies(1): >>41282049 #

5. throwaway290 ◴[18 Aug 24 12:43 UTC] No.41282040[source]▶

>>41279963 #

Just like the original comment praising Spring, too. It's always the developers. Whether you use one framework or another or nothing.

6. tonyarkles ◴[18 Aug 24 12:44 UTC] No.41282049{4}[source]▶

>>41281873 #

I'm explaining why I have had a bad experience with Spring. Spring is the only framework I've used that does weird stuff with annotation-based DI and can silently fail in production by default due to those annotations not being resolved correctly at runtime (heck, even if they can't be resolved at compile-time, please make them fail at startup instead of later!).

I've had other issues with other non-Java frameworks too, but I'm not giving a comprehensive write-up of the pros and cons of every web framework I've ever used here... just pointing out the pain points I had with Spring.

I also didn't mention LOMBOK because that doesn't seem like it's necessarily part of Spring by default but wow did that also prove to be another source of painful bugs.

replies(1): >>41282565 #

7. literallyroy ◴[18 Aug 24 14:22 UTC] No.41282565{5}[source]▶

>>41282049 #

Spent a good day debugging, to learn that some (most?) annotations don’t work when the method is called from inside the same class (no proxy is setup).

↑