←back to thread

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

(github.com)
74 points holmofyHu | 2 comments | 17 Aug 24 12:40 UTC | HN request time: 0.4s | source
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. signal11 ◴[18 Aug 24 13:52 UTC] No.41282389[source]▶
> You'll get it when you make it to true Senior level :)

This and the following lines have so many opinions presented as truisms, it’s difficult to take the poster seriously.

2-4 “senior” devs were spending time on tech-only features without delivering actual end-user / business features. Ookay. Seems like a failure of engineering management, but let’s press forward.

2-4 engineers replaced with 1 “true Senior” engineer, who rewrote the microservices nightmare into a monolith powered by Spring. And he had C Suite backing for this. All’s well now.

I mean, that’s a great result. But it feels like there’s also some great people/motivation backstory we’re not getting. Also, maybe lessons from a one-person monolith don’t apply everywhere, even if that monolith serves millions of users?

replies(1): >>41288392 #
2. npstr ◴[19 Aug 24 06:36 UTC] No.41288392[source]▶
You don't have to take me serious to derive value from the post. It's obvious anecdotal, just shares a story. I skipped some of the details to focus on the topic of Spring. But I think I can add some as you have rightly spotted they are missing: The major problem was imho indeed engineering management of that specific team, which was also swapped out at the same time I was put on the team (which was before we got the buy in to rewrite it). There were actually at least two dev generations of the team building the software before ours. The first one caused the most damage by the demented infrastructure decisions, while the second iteration was not able to successfully challenge that, even though they had the right ideas already. New engineering management was awesome in that they supported devs with most of our radical ideas, but also pulled in resources from other departments to help deal with the largest pain points such as adding Spring Boot quite early in the mending journey, with the heavy lifting being done by an expert from another team temporarily joining us.

Forgive my judgy wordings in the direction of seniority...our org has (had?) an issue where complexity is rewarded over simplicity. Some senior people here all they could do is build something so clusterfucked noone can understand it. Funnily enough, this project was originally launched to replace a legacy system noone was able to (or unwilling to) maintain.