For more QCon posts, see my live blog table of contents.

General notes

• Spring 5 has reactive features.
• Maybe a third of the audience is doing something with reactive, a little more have read about it (that’s me) and a lot haven’t heard of it. Which is good given the title of this talk!
• Moore’s law slowing down. No more free lunch from the hardware
• Now apps more distributed/independent/cloudbased compared to 10 years ago
• Now we expect latency
• Thread now has to do more async things. Hit limits of scale. imperative logic more complicated.

Other approach

• Async/non-blocking
• Use very few threads. node.js has a single thread. Must be careful because blocking those few threads blocks the whole app
• Reactive programming – think async. Not everything is a callback

Comparing styles

• Imperative
  • call a method, get a result, do something with that result
• Async
  • return a Future instead of a value. Don’t throw a checked exception because my happen in a different thread. They are asynchronous in that you can get a result later. But when you eventually call feature.get(), it throws different checked exceptions.
  • In Java 8, can return a CompletableFuture and call future.whenComplete((user, throwable) -> {})
  • If doing a findAll(), the future/completable future approach doesn’t give you a callback/return anything until all of them are ready. You can’t stream or could run out of memory.
  • Async results as stream – get one notification per data item and another for completion or error
• Declarative
  • Focus on what, not how
  • Declare what should happen rather than focusing on callbacks
  • Java 8 stream API uses this style. It is meant for collections and pull based/usable once
  • Hot streams – latency sensitive streams, data need to be pushed for you
  • Cold streams – pull based

Reactive libraries

• Stream like API
• Can be used for hot/cold streams
• Project Reactor – Similar to ReactiveX, easy to bridge to Java 8 streams. (ReactiveX is like XUnit – commonality for different languages)

Abstractions

• Flux – sequence of 0 to n – equivalent of Java 8 stream – can convert to/from Java 8
• Mono – sequence of 0 or 1 – can convert to/from CompletableFuture

Reactive streams spec

• Back pressure – producers must not overwhelm consumers. Communicates if downstream isn’t ready for more items. Ex: a slow client like a mobile device isnt able to handle more data and server isn’t blocking
• Small API – only 4 interfaces
• Rules
• Interoperability across reactive components so can compose chain

Java 9

• Reactive streams included (the four interfaces)
  • Publisher
  • Subscriber
  • Subscription
  • Processor
• Use a reactive library. Don’t implement the four interfaces yourself
• subscribe() triggers the flow of data
• “push” was missing until now. Want in JDK to have foundation
• Classes
  • java.util.concurrent.Flow – the four interfaces
  • SubmissionPublisher – bridge to reactie streams
  • Tie-ins to CompletableFuture and Stream

Reactor

• GA release scheduled for July
• Currently called 2.5. Might changed to 3.0

Reactive Spring MVC

• Apps annotate controllers even now.
• Return a Flux type.
• Spring MVC itself needs to change a lot – called Spring Web Reactive
• The servlet API assumes blocking. There are async workarounds. Servlet 4.0 might support reactive spring integration, but probably just the basics. Using own bridge to Servlet 3.1 in meantime.
• Can still use Jetty/Tomcat. They are non-blocking behind the scenes.
• Don’t need servlet container. Can use Netty.
• HandlerMapping – change to return a Mono so can be non-blocking
• Focusing on REST/microservices scenarios

Other reactive efforts

• MongoDB – reactive driver
• Couchbase – reactive driver
• Thymeleaf – split templates into chunks and throttle to respect backpressure