re: Java vs Go: Impressive solutions for invented problems VIEW POST

re: There is of course no reason why it has to be like this, Java does not mandate this style of coding, but it's become a bit of a "tradition" in the ...

In the early days, you don't understand Spring enough to see the benefits... in the middle, you love it... and towards the end, you realise just how much it gets in your way.

I couldn't have put it better 👍
This is exactly it.

Once you've learned the ropes with Spring:

  • You start a new project
  • You're glad to have Spring Boot to quickly bootstrap your app: the embedded tomcat server, the magic auto-discovery of your various config classes and beans, the transparent transaction handling, security, ...
  • Then you start a slow and never-ending cycle of fighting with the framework
  • You get a bug report: if I call the endpoint GET /tax/{code} with something with a dot in it, e.g. vat.20, I get a 500 error No serializer configured for the "20" media type
  • Furiously Google for the magic bean to override to tell Spring not to infer the response type from the extension in the path
  • Don't even get me started on the Spring Security mess: a supposedly extensible setup with dozens and dozens of beans, but good luck understanding the intricate inter-bean relations, which ones to override, how to )safely) override them, ... (I have so many horror stories wrt. the JWT part for example)

Spring Security

I'm yet to find a valid reason to include Spring Security in any corporate project. It's simply not maintainable enough for our use-case(s).

the fear factor: "Are you really sure you want to reimplement your own security stack instead of going of the industry standardm battle-proven 15 year old Acegi/Spring Security stack ?" ¯_(ツ)_/¯

Re-inventing the wheel is not a good thing. There's options that aren't Spring Security. For example, for those that for some reason like XML, there's Shiro.

Our model though is that Front End applications implement security properly, and the middleware/backend treats the front end as a trusted component with very basic security requirements. This way, the Front End gets penetration tested and we don't have duplicated code/effort in the security layer. We don't have any Front End applications in Spring, and very few in Java.

Code of Conduct Report abuse