4 ms·
Isn'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.", sho
by raudbjorn 9y ago
Isn'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"