3 ms·
Why Spring Boot? Just curious. I work with it daily and have grown to detest it.
by strictfp 9y ago
Why Spring Boot? Just curious. I work with it daily and have grown to detest it.
- mping 9y agoIf you stick to the script its ok. But the script sucks right? I prefer dropwizard + libs, always end up googling how to do X with spring boot, where X is a bit off the beaten path
- _pmf_ 9y ago> I work with it daily and have grown to detest it. What exactly do you hate? (I feel weird liking Spring quite a bit, and would like to get in on the hatin' ...)
- strictfp 9y agoTo be as concise as I can, I would say that Spring Boot is a framework which minimizes the amount of "code" you have to write at the cost of everything else. And this means that it's hard to understand what is going on under the covers, hard to debug (partly due to metaprogramming bananza), slow to start, uses too much CPU, uses huge amounts of stack, has all bells and whistles turned on by default etc etc. It gives you all errors at runtime. Encourages you to make your app too configurable (hard to test all configs). Reimplements a bunch of tools and libs badly (like one-jar). Its also intrusive like all frameworks. Requiring a custom test runner is not a feature, Spring! For these type of reasons you cannot easily integrate it with other frameworks. And that is just from the top of my head.
- giobox 9y ago> "all bells and whistles turned on by default etc" Arguably a little unfair? Spring boot makes it pretty trivial to just pick and choose the components you need for a project, especially with the https://start.spring.io/ https://start.spring.io/ tool. > Requiring a custom test runner is not a feature, Spring! I'm guessing this is a reference to using Spring's test runner to support Spring's dependency injection mechanism? No one forces you to use this so it's a stretch to say its 'required', but for certain tests it will save time over manually mocking etc, and often only applies to integration tests anyway. You can absolutely unit test without it. > "It gives you all errors at runtime." I'm sure it does, if you have errors. > "Encourages you to make your app too configurable" Spring boot apps are only as configurable as you make them, much like any other application. At least Spring tries to provide a standardized methodology/pattern for externalizing configuration parameters. I fail to see the 'encouragement'. > you cannot easily integrate it with other frameworks. It's java at the end of the day - there's a ludicrous number of third party frameworks it will play nicely with. > slow to start, uses too much CPU Sure JVM applications rarely have 'instant' startup for various reasons, but is a handful of seconds really a problem? 'Uses too much CPU' - I don't really think this is fair either - Spring Boot applications can deliver very efficient solutions. Not going to argue it's the perfect choice for every project, but no framework is.
- raudbjorn 9y agoIsn't spring boot "thread-per-request"? Some people care about that kind of performance-related stuff. Also, I think "It gives you all errors at runtime.", should have been "It doesn't give you the errors other frameworks are able to give you at compile time." -and I kind of agree, if memory serves "Spring" is sort of synonymous with "reflection", which isn't exactly performant either. EDIT: Wow, just read my comment and realized it comes across like I really hate Spring. I don't, I think it's nice. It's great for web apps that have human users; for services that are consumed by other services, I would probably go for something else.
- polotics 9y agoSpring? If you need Java DI you will find Guice fixed the warts.
- raudbjorn 9y agoOr dagger 2. :)
- penetrarthur 9y agoDoes it have Auth and so much more Spring has to offer?
- Traubenfuchs 9y agoWhat's "thread-per-request" to you exactly? By default, Spring Boot uses an integrated Tomcat in standalone mode. That Tomcat is configured to use a worker threadpool with a default size of 200. In addition to that you can make Controller methods "asynchronous" (as in free the worker thread as soon as possible) by simply wrapping the methods content in a Callable<T>, which amounts to wrapping it in a lambda method. Calling methods asynchronously is trivial as well, you just need to annotate them with @Async and wrap your result in an AsyncResult<T>. If you follow the reactive/async/callback/functional cargo cult you can use the brand-new, already usable Spring 5.x spring-webflux. As they describe it: "fully reactive and non-blocking. It is suitable for event-loop style processing with a small number of threads"