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)
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I couldn't have put it better 👍
This is exactly it.
Once you've learned the ropes with Spring:
GET /tax/{code}with something with a dot in it, e.g.vat.20, I get a 500 errorNo serializer configured for the "20" media typeI'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.