Designing, Implementing, and Using Reactive APIs
summary
A reactive Java client for Cloud Foundry is implemented on Project Reactor (Reactor 3.x) to handle 550–600 Cloud Foundry APIs with nonblocking IO, using Mono/Flux as the public types, returning monos even for collections, and composing small reusable methods for paging and orchestration. Testing uses StepVerifier instead of blocking, production code measures hundreds of thousands of lines and thousands of tests, and blocking is confined to isolated thread pools or edges to avoid degrading Netty servlet threads.
AI-written summary · about
chapters (27)
- 0:00Intro
- 2:13Introduction to Reactive Programming
- 5:08Cloud Foundry Java Client
- 8:04Generic Request and Response Payloads
- 8:38Strongly Typed Request and Response Payloads
- 12:26When To Use Reactive
- 17:04What Should a Reactive API Return?
- 18:44Using a Flux Response
- 19:42Using a Mono Response
- 22:39Imperative Operation
- 23:02Reactive Operation
- 25:01Scope of a Method
- 26:58Reusable Methods
- 29:10Sequential and Parallel Coordination
- 31:35Error Logic
- 33:26Empty Logic
- 36:21Conditional Logic Avoiding Imperative
- 38:53Conditional Logic Using Imperative
- 40:14Test Finishing Before Assertions
- 41:11Test Blocking Using CountDownLatch
- 42:22Testing using StepVerifier
- 42:56Test Multiple Values
- 44:12Test Expected Error
- 45:01Countdown Latches
- 48:02Blocking Flows
- 50:55Error Handling
- 51:37Bridging Imperative and Reactive using block()
related talks
51mReactor 3, the reactive foundation for Java 8 (and Spring 5)
06mPhil Clay at SpringOne 2020
53mRefactor to Reactive with Spring 5 and Project Reactor
56mKEYNOTE - Designing Applications: The Reactive Way
46mMoving from Imperative to Reactive
01h 01mReactive web services
41mThe definite guide to reactive programming in Java
29mBuilding Reactive Systems with Reactor