Project Reactor (reactor-core)

Reactive Streams library for JVM. Provides Mono<T> (0-1 items) and Flux<T> (0-N items) reactive types with operators for transformation, filtering, combining, and error handling. The foundation of Spring WebFlux, R2DBC reactive databases, and reactive microservices. Implements the Reactive Streams specification for interoperability with RxJava, Akka Streams, and other reactive libraries.

Evaluated Mar 06, 2026 (0d ago) v3.6+
Homepage ↗ Repo ↗ Developer Tools reactive java kotlin spring webflux flux mono backpressure r2dbc
&#9881; Agent Friendliness
64
/ 100
Can an agent use this?
&#128274; Security
86
/ 100
Is it safe for agents?
&#9889; Reliability
84
/ 100
Does it work consistently?

Score Breakdown

⚙ Agent Friendliness

MCP Quality
--
Documentation
85
Error Messages
78
Auth Simplicity
90
Rate Limits
90

🔒 Security

TLS Enforcement
92
Auth Strength
86
Scope Granularity
82
Dep. Hygiene
88
Secret Handling
85

Reactive library — no direct security surface. Spring Security reactive provides comprehensive auth on top of Reactor. VMware/Spring maintains with regular CVE patches.

⚡ Reliability

Uptime/SLA
88
Version Stability
85
Breaking Changes
80
Error Recovery
82
AF Security Reliability

Best When

You're building Spring WebFlux services or need high-concurrency non-blocking I/O in JVM backend agent services with reactive data access.

Avoid When

You're not using Spring WebFlux or R2DBC — for general async JVM code, Kotlin coroutines are more readable and less error-prone.

Use Cases

  • Build non-blocking Spring WebFlux agent API services using Mono/Flux return types for reactive HTTP handlers
  • Chain agent pipeline operations (fetch, transform, store) without blocking threads — Flux operators compose async operations functionally
  • Use R2DBC with Reactor for fully reactive agent data access from PostgreSQL and other R2DBC-compatible databases
  • Use Reactor's Schedulers to shift CPU-intensive agent work to dedicated thread pools without blocking the reactive event loop
  • Handle backpressure in agent streaming pipelines with Flux.limitRate() and custom subscribers to prevent memory overflow

Not For

  • Simple async code without reactive requirements — Kotlin coroutines or CompletableFuture are simpler for agent code that doesn't need reactive operators
  • Teams unfamiliar with reactive programming — Reactor has a steep learning curve; bugs from wrong Schedulers or missing subscriptions are hard to debug
  • Android development — Kotlin coroutines and Flow are the Kotlin-native reactive primitives; Reactor is JVM server-side only

Interface

REST API
No
GraphQL
No
gRPC
No
MCP Server
No
SDK
Yes
Webhooks
No

Authentication

Methods: none
OAuth: No Scopes: No

Reactive library — no authentication. Auth implemented in Spring Security reactive layer on top of Reactor.

Pricing

Model: open_source
Free tier: Yes
Requires CC: No

VMware/Spring project under Apache 2.0. Free for all use.

Agent Metadata

Pagination
none
Idempotent
Full
Retry Guidance
Documented

Known Gotchas

  • Reactor pipelines are lazy — creating a Mono/Flux does nothing until subscribe() is called; common agent bug is creating a pipeline without subscribing and wondering why nothing happened
  • Blocking calls inside reactive operators (Mono.map with Thread.sleep(), JDBC calls) block the reactive scheduler thread and can deadlock the event loop; use subscribeOn(Schedulers.boundedElastic()) to wrap blocking calls
  • Error handling in Reactor must be explicit — uncaught exceptions in operators cause the stream to terminate; use onErrorResume(), onErrorReturn(), or onErrorMap() to handle errors gracefully
  • Context propagation (MDC, security context) is not automatic in reactive code — use Reactor Context and ContextView.put() to propagate agent request IDs and auth context through the chain
  • Flux.zip() and Flux.combineLatest() require all sources to emit — if one source completes before emitting, the entire zip completes; use zipWith default values for optional sources
  • Hot vs cold publisher behavior: Flux.just() and database queries are cold (replay on each subscribe); Flux.share() and Sinks are hot (shared among subscribers) — agents must understand which they need

Alternatives

Full Evaluation Report

Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Project Reactor (reactor-core).

$99

Scores are editorial opinions as of 2026-03-06.

5215
Packages Evaluated
26151
Need Evaluation
173
Need Re-evaluation
Community Powered