VMware offers training and certification to turbo-charge your progress.Learn more
Oh emm geee y'all! We just released Spring Framework 5.2, complete with new RSocket support, and a slew of projects have followed suit in the intervening... day! I expect we'll see more soon, followed not too far behind by Spring Boot! And, of course, next week is the biggest week in all of Springdom every week: SpringOne Platform 2019!
I can't wait to get there, but first I'm off to Taipei for the JCCConf. THere's a ton to get to let's dive right in!
Reactive programming and Loom aim for different goals. Reactive is all about message passing and events, Loom is about scheduling.
With Loom, consumption of streaming sources (Pub/Sub, change stream, live queries) remains as ugly as it currently is (Listeners, Message Containers). So basically, your code remains the same. You still require multiple server roundtrips or even query executions ("Paging") to fetch a lot of data and latency behavior stays as-is because most APIs return a List. Your code has still to wait until a response arrives as today's imperative drivers aren't backpressure-aware and cannot request data while you're processing the chunk you previously received.
With Reactive Streams, any stream of data (Pub/Sub, change stream, live queries) is just yet another Publisher
. Consuming unbounded data sources does not look any different than consuming a query with a bounded result count.
A proper, non-blocking Reactive Streams implementation comes with improved latency behavior because a Reactive Streams database driver can pre-fetch data from cursors as it is backpressure-aware. A stream does not require pagination for the sake of fetching lots of data because each element is emitted individually and there's no need in the first place to aggregate data to a List. You get much better memory and latency characteristics by design.
@SpyBeanbut for MockK, not Mockito