Reactive Application Design with Spring 5, Hamburg Reactive Systems Meetup

The 5th version of the Spring Framework brings a huge step forward in Functional and Reactive Programming support. You don't need ApplicationContext or dozens of annotations to have the simplest REST API up and running. Spring 5 will offer lightweight Web Functions and reactive Web Flux support that can help this transition happen. Those new features make Java and Spring 5 good candidates for building reactive web applications. In addition, we will cover Reactive Systems design principles in general as well as some Resilience Patterns. The talk itself doesn't rely on prior Spring Framework experience so that participants without Spring background could attend the presentation.

More about the event: https://www.meetup.com/Reactive-Systems-Hamburg/events/239818441/

Transcript

1. Reactive Application Design with Spring 5 Grygoriy Gonchar (@ggonchar) @Kreditech
2. Spring 5 Reactive programming Functional style with Java 8 & Kotlin Integration with Java EE 8 APIs Ready for JDK 9
3. The Reactive Manifesto
4. Reactive Programming
5. Reactor Project https://github.com/reactor/reactor
6. Mono & Flux
7. Mono[0|1|Err] like CompletableFuture
8. Mono Mono<String> m = Mono .fromCallable(() -> "First") .map(t -> t + " and Second") .filter(t -> t.length() % 2 == 0)
9. 100+ operators
10. Optional semantic Mono<String> m = Mono .fromCallable(() -> "First") .map(t -> t + " and Second") .filter(t -> t.length() % 2 == 0) .defaultIfEmpty("Empty");
11. Nothing happens until you subscribe() Mono .fromCallable(() -> "First") .map(t -> t + " and Second") .filter(t -> t.length() % 2 == 0) .defaultIfEmpty("Empty") .subscribe(System.out::println, System.err::println);
12. Never block() String s = Mono .fromCallable(() -> "First") .map(t -> t + " and Second") .filter(t -> t.length() % 2 == 0) // with various operators .defaultIfEmpty("Empty") // and Optional semantic .block();
13. Composable Mono.first(getMonoA(), getMonoB()) .timeout(Duration.ofSeconds(3)) .subscribe(this::success, this::fallback);
14. Flux[N|Err] like Stream with Backpressure
15. Flux Flux<Integer> f = Flux.fromIterable(Arrays.asList(1, 2, 3)) .filter(t -> t % 2 == 0) .map(t -> t * 2);
16. Parallel and Asyc When Required Flux<Integer> f = Flux.fromIterable(Arrays.asList(1, 2, 3)) .parallel().runOn(Schedulers.parallel()) .filter(t -> t % 2 == 0) .map(t -> t * 2);
17. Interoperable with Mono Mono<Integer> m = Flux.fromIterable(Arrays.asList(1, 2, 3)) .parallel().runOn(Schedulers.parallel()) .filter(t -> t % 2 == 0) .map(t -> t * 2) .reduce((t1, t2) -> t1 * t2);
18. Integrated with Reactive Streams Mono<Integer> m = Flux.from(publisher) // Reactive Streams Publisher .parallel().runOn(Schedulers.parallel()) .filter(t -> t % 2 == 0) .map(t -> t * 2) .reduce((t1, t2) -> t1 * t2);
19. Reactive Streams
20. Controlling Back-Pressure Mono<Integer> m = Flux.from(publisher) // Reactive Streams Publisher .buffer(300) // communicating demand .parallel().runOn(Schedulers.parallel()) .filter(t -> t % 2 == 0) .map(t -> t * 2) .reduce((t1, t2) -> t1 * t2);
21. Back-pressure Async message consumption or big datasets bring back-pressure need On back-pressure stop demanding (pull-based back-pressure) Otherwise drop messages or signal an error in controlled manner
22. Application Example Has some business logic Integrates with others Persists data Data intensive Uses blocking implementations Resilient Well-tested
23. Entity public class Person { private String id; private String firstname; private String lastname; private String ipAddress; private IpAddressDetails ipDetails; private List<Person> friends; // ... }
24. Business Logic public Person addPerson(Person person) { IpAddressDetails ipDetails = ipService.getDetails(person.getIpAddress()); person.setIpDetails(ipDetails); return repository.save(person); }
25. http://ip-api.com/json/8.8.8.8 { "city":"Mountain View", "country":"United States", "countryCode":"US", "org":"Google", …
26. Reactive WebClient public Mono<IpAddressDetails> geDetails(String ip) { return WebClient.create("http://ip-api.com/") .get().uri("/json/{ip}", ip).exchange() .then(response -> response.bodyToMono(IpAddressDetails.class)); }
27. Reactive Spring Data public interface ReactiveCrudRepository<T, ID> extends Repository<T, ID> { Mono<T> save(T var1); Mono<T> findById(ID var1); Flux<T> findAll(); Mono<Long> count(); ...
28. Save Person with Reactive Spring Data public interface PersonRepository extends ReactiveCrudRepository<Person, String> { // <S> Mono<S> save(S var1); }
29. Business Logic (Composition of Monadic Types) private Mono<Person> addPerson(Mono<Person> mono) { return mono .flatMap(this::addIpDetails) .flatMap(repository::save); }
30. Business Logic (Nested Monadic Composition) public Mono<Person> addPerson(Mono<Person> mono) { return mono .flatMap(this::addIpDetails) .flatMap(repository::save); } private Mono<Person> addIpDetails(Person person) { return ipService.getDetails(person.getIpAddress()) .map(details -> person.copyWithIpDetails(details)); }
31. Functional Programming and Reactor Reactor & Spring 5 forces to use declarative asynchronous functional approach Reactor & Spring 5 doesn’t force purely functional idiomatic (like scalaz, http4s, doobie in Scala) Knowledge of Functional Programming patterns can be useful (such as functional errors, monad transformers, optics etc.)
32. Local Variable Capture and Mutability public Mono<Person> addPerson(Mono<Person> mono) { return mono .flatMap(this::addIpDetails) .flatMap(repository::save); } private Mono<Person> addIpDetails(Person person) { return ipService.getDetails(person.getIpAddress()) .map(details -> person.copyWithIpDetails(details)); }
33. Mutability Evil “Mutable state is the new spaghetti code” - Rich Hickey, Clojure's inventor
34. Immutability public final class Person { private final String id; private final String firstname; private final String lastname; private final String ipAddress; private final IpAddressDetails ipDetails; // immutable inside private final javaslang.collection.List<Person> friends; // immutable // init constructor and only getters }
35. Immutability in Practice Problems with reflection libraries: No default constructor for entity No interoperable immutable collections: Javaslang, Guava, JDK9 If done right another challenges come: builders, aggregates, lenses Has better support in Scala, Clojure, Kotlin (and Spring 5 brings Kotlin)
36. Reactive REST API @PostMapping("/person") public Mono<Person> addPerson(Person p) { return service.addPerson(p); } @GetMapping("/person") public Flux<Person> findAll() { return service.findAll(); }
37. Web Functions return RouterFunctions .route(POST("/person"), request -> { final Mono<Person> p = addPerson(request.bodyToMono(Person.class)); return ServerResponse.ok().body(p, Person.class); }) .andRoute(GET("/person"), request -> ServerResponse.ok().body(repository.findAll(), Person.class) );
38. Design Options
39. Data Intensive Processing with Backpressure LocalDateTime dateTime = LocalDateTime.now().minusDays(90); return repository.findByUpdatedAtLessThan(dateTime) .flatMap(this::updateIpAddressDetails);
40. Data Intensive Processing with Backpressure LocalDateTime dateTime = LocalDateTime.now().minusDays(90); return repository.findByUpdatedAtLessThan(dateTime) .buffer(300) // communicating demand .flatMap(this::updateIpAddressDetails);
41. Data Intensive Processing with Backpressure LocalDateTime dateTime = LocalDateTime.now().minusDays(90); return repository.findByUpdatedAtLessThan(dateTime) .buffer(300) // communicating demand .parallel(2) // speed-up execution .runOn(Schedulers.newParallel("ipUpdateScheduler", 2)) .flatMap(this::updateIpAddressDetails);
42. Application Example Has some business logic Integrates with others Persists data Data intensive Uses blocking implementations Resilient Well-tested
43. Non-Blocking SQL != JDBC
44. Spring Data JPA public interface PersonRepository extends CrudRepository<Person, String> { // Iterable<T> findAll(); }
45. “Reactive” Spring Data JPA public interface PersonRepository extends CrudRepository<Person, String> { // Iterable<T> findAll(); } private Mono<Iterable<Person>> findAll() { return Mono.fromCallable(() -> repository.findAll()); }
46. “Reactive” Spring Data JPA public interface PersonRepository extends CrudRepository<Person, String> { // Iterable<T> findAll(); } private Mono<Iterable<Person>> findAll() { return Mono.fromCallable(() -> repository.findAll()) .publishOn(jdbcScheduler); } @Qualifier("jdbcScheduler") private Scheduler jdbcScheduler;
47. Dedicated Thread Pool for JDBC @Value("${spring.datasource.maximum-pool-size}") private Integer connectionPoolSize; @Bean public Scheduler jdbcScheduler() { return Schedulers.fromExecutor( Executors.newFixedThreadPool(connectionPoolSize)); }
48. Threads Distribution Example
49. Isolated Asynchronous JDBC (Scala SQL Library)
50. Resilient Systems “They meet failure with elegance rather than disaster” - The Reactive Manifesto
51. Service with External Dependencies
52. External Dependencies Fail
53. Cascading Failures Occur
54. Thread Pools as Bulkheads
55. Circuit Breaker
56. Circuit Breaker Useful to provide your clients fail response fast (better UX) Useful when fallback available (such as fallback service provider) Useful to let your dependencies recover
57. Circuit Breaker Example with resilience4j return CircuitBreakerConfig.custom() .failureRateThreshold(10) .build();
58. Circuit Breaker Example with resilience4j return CircuitBreakerConfig.custom() .failureRateThreshold(10) .waitDurationInOpenState(Duration.ofMinutes(5)) .build();
59. Circuit Breaker Example with resilience4j return CircuitBreakerConfig.custom() .failureRateThreshold(10) .waitDurationInOpenState(Duration.ofMinutes(5)) .ringBufferSizeInClosedState(100) .build();
60. Circuit Breaker Example with resilience4j return CircuitBreakerConfig.custom() .failureRateThreshold(10) .waitDurationInOpenState(Duration.ofMinutes(5)) .ringBufferSizeInClosedState(100) .ringBufferSizeInHalfOpenState(30) .build();
61. Example Scenario return getIpAddressDetails(ip).map(this::parse);
62. Circuit Breaker Example with resilience4j return Try.of(CircuitBreaker.decorateCheckedSupplier(circuitBreaker, () -> getIpAddressDetails(ip) )).getOrElse(() -> getIpAddressDetailsFallback(ip)) .map(this::parse) .onErrorReturn(EMPTY_IP_INFO);
63. Circuit Breaker Example with resilience4j return Try.of(CircuitBreaker.decorateCheckedSupplier(circuitBreaker, () -> getIpAddressDetails(ip).onErrorResume(t -> { circuitBreaker.onError(Duration.ZERO, t); return getIpAddressDetailsFallback(ip); }) )).getOrElse(() -> getIpAddressDetailsFallback(ip)) .map(this::parse) .onErrorReturn(EMPTY_IP_INFO);
64. resilience4j can do more Circuit breaking Bulkheading Automatic retrying Rate limiting Response caching Timeout handling
65. Testing Reactive Application You can block() in tests Use testing features of your reactive library (like reactor-test) Test your resilience (with or without tools like Netflix's Chaos Monkey) Load test with expected throughput
66. Conclusions
67. Conclusions Never block to stay Reactive (flatMap them all) Using Blocking IO libraries (such as JDBC) still possible Non-blocking functional programming might give mental overhead Not every application has high enough throughput Blocking can still be resilient, responsive and fast Use Resilience Patterns (such as Bulkheads, Circuit Breaker) in addition
68. Recommended Books
69. Slides & Code Slides https://twitter.com/ggonchar Code https://github.com/ggonchar/reactive-spring5-example