3 ms·

>while running it in production over time I think it has costs I'd rather not pay so I suppose a better framework would excite me too. can you elaborate on thi

>while running it in production over time I think it has costs I'd rather not pay so I suppose a better framework would excite me too. can you elaborate on this ? really have been considering spring boot, etc. But coming from the python world ...i feel it cognitively very hard to get through. But im super keen to know what issues come in production. Most of us were under the impression that Spring in production just works. >so I suppose a better framework would excite me too especially from this perspective. What would you want ?

zaphar 4y ago
My complaint about spring is the same complaint I have about almost every runtime dependency injection framework. In the happy path everything just works. But when you get off that happy path which happens all the time in production for any system older than a month you get exceptions and those exceptions list stuff in the stack trace that you've never seen and didn't even know were being used. For those issues every once in a while when you try to dig into the error you find yourself deep into runtime reflection code somewhere trying to figure out how this particular configuration happened. How your code got glued together is a mass of difficult to read code buried deep in the spring framework. We have a saying about these types of frameworks: They are a great way to turn compile errors into runtime errors. When you are just starting out on a project it's great. You get up and running fast and as long as stuff doesn't change too much you are probably fine. But when your codebase reaches 5+ years of age it's highly likely to see a spike in "runtime errors" that potentially could have been compile time errors every time you release and releases get nerve wracking for a bit until eventually the codebase get's frozen in stone and someone starts suggesting we rewrite it.
- zaphar 4y ago
  I should mention that this isn't the fault of dependency injection itself. It's the natural result of doing that dependency injection at runtime using reflection. A better way is to use code generation so that you can actually see and reason about the code when something goes wrong.

zaphar 4y ago

My complaint about spring is the same complaint I have about almost every runtime dependency injection framework. In the happy path everything just works. But when you get off that happy path which happens all the time in production for any system older than a month you get exceptions and those exceptions list stuff in the stack trace that you've never seen and didn't even know were being used. For those issues every once in a while when you try to dig into the error you find yourself deep into runtime reflection code somewhere trying to figure out how this particular configuration happened. How your code got glued together is a mass of difficult to read code buried deep in the spring framework. We have a saying about these types of frameworks: They are a great way to turn compile errors into runtime errors. When you are just starting out on a project it's great. You get up and running fast and as long as stuff doesn't change too much you are probably fine. But when your codebase reaches 5+ years of age it's highly likely to see a spike in "runtime errors" that potentially could have been compile time errors every time you release and releases get nerve wracking for a bit until eventually the codebase get's frozen in stone and someone starts suggesting we rewrite it.

zaphar 4y ago
I should mention that this isn't the fault of dependency injection itself. It's the natural result of doing that dependency injection at runtime using reflection. A better way is to use code generation so that you can actually see and reason about the code when something goes wrong.