hantsy/spring-reactive-sample: Spring WebFlux and Reactive Data Examples

What spring-reactive-sample Covers

hantsy/spring-reactive-sample solves a learning and experimentation problem. It provides separate Java projects for examining how Spring handles Reactive Streams across web handling, application code, persistence, messaging, security, and client calls. The repository description calls it a playground, and the README uses the term sandbox project. That framing matters. The code is organized around examples with different integrations and runtime choices, not around a single deployable product.

The intended audience is developers who already know Spring basics and want concrete examples of Spring WebFlux, Spring Data reactive APIs, or related reactive libraries. The repository covers Reactor through the standard Spring examples, RxJava 3 through the rxjava3 directory, and SmallRye Mutiny through the smallrye-mutiny directory. It also includes examples based on Cassandra, Couchbase, Elasticsearch, MongoDB, Neo4j, and Redis. Reactive security, multipart handling, pagination, transactions, functional routes, and Kotlin samples are represented as separate modules.

This is not a thin demonstration of one endpoint. The README lists many variations that let a reader compare declarative controllers with functional routing, Jetty with Tomcat and Undertow, hard-coded security users with users.properties and a MongoDB-backed user store, and basic data access with paging, transactions, message listeners, or GridFS. The trade-off is breadth. A repository with many modules can create dependency and configuration differences between examples, so readers must treat each directory as a separate sample project.

WebFlux Modules and Reactive Library Choices

The vanilla module is described as basic spring-webflux functionality with a main class that starts the application. The runtime-specific directories make the same basic example available through vanilla-jetty, vanilla-tomcat, and vanilla-undertow. This is a useful way to separate application code from server selection. It also makes clear that the repository is not claiming that reactive behavior depends on one embedded server. The README presents the server choice as a module-level variation.

Other examples change the programming model or the surrounding infrastructure. The routes module uses RouterFunction instead of @Controller. The register-bean module performs programmatic bean registration in the ApplicationContext at bootstrap. The war module replaces the manual bootstrap with Spring ApplicationInitializer and can be packaged as a war file for external servlet containers. These samples are particularly useful when the question is not simply how to return a reactive value, but how Spring wires or bootstraps a reactive application.

The rxjava3 and smallrye-mutiny modules are documented as alternatives to the vanilla Reactor-oriented example. That comparison is conceptually important. Reactor is the default reactive library associated with Spring WebFlux examples, but the repository shows that a Spring application can be examined with another implementation of reactive types. The README does not claim that every Spring Data integration supports every library equally. A reader should therefore verify the module's dependencies and return types before transferring a pattern from Reactor to RxJava 3 or Mutiny.

The repository also includes client-oriented modules such as client, client-jetty, client-apache-httpclient5, and client-jdk11-httpclient. Those directories indicate coverage of reactive client implementations and server choices, although the README does not document their exact commands or complete API contracts. The repository layout is enough to establish scope, not enough to infer every request path or configuration value.

Reactive Data Samples and Service Dependencies

The data modules demonstrate that reactive application code extends beyond WebFlux controllers. The README names Spring Data reactive examples for Elasticsearch, Neo4j, MongoDB, Redis, Cassandra, and Couchbase. It also calls out data-mongo-pageable for pagination, data-mongo-transaction for transaction support, data-redis-message for ReactiveRedisMessageListenerContainer, and multipart-data-mongo for storing uploaded files through Spring Data Mongo Reactive GridFsTemplate.

The repository's docker-compose.yml supplies the service definitions that correspond to many of these examples. It defines cassandra on port 9042, redis on 6379, postgres on 5432, mongodb on 27017, couchbase management and data ports, elasticsearch on 9200 and 9300, and neo4j. The compose file also defines named volumes for several services and configures Elasticsearch as a single node. PostgreSQL is configured with database name test, user user, and password password. Neo4j is configured with NEO4J_AUTH=neo4j/test.

This is useful for local experimentation, but it is also a source of deployment boundaries. The compose file uses broad image tags such as cassandra, redis, postgres, mongo, couchbase, and neo4j, while Elasticsearch is pinned to 7.17.4. The README does not document a complete startup procedure, image compatibility matrix, or production security configuration. The examples should not be treated as a ready cluster definition.

The data directories also show that reactive persistence is not one uniform operation. Paging, transactions, tailable cursors, template access, and message listening have different APIs and failure conditions. A sample that works with one store does not establish that the same code works with another. The repository is best used to inspect the integration pattern for the store named in the module, then compare its assumptions with the application's actual database version and client behavior.

Installing a Sample and Choosing Its Version

The README directs readers to the online documentation and links to the source directories, but it does not provide a complete install or run command for a specific sample. It also does not give a universal command that starts every module. For that reason, no command block is included here. The concrete entry points documented by the repository are the online documentation, the default master branch, and the boot-3 and v1.0 archives and tags.

A first use should begin with the documentation and one simple module such as vanilla. The README describes vanilla as the basic spring-webflux example, which makes it a more suitable starting point than a data or security module. Before running a persistence example, use docker-compose.yml to establish the named service required by that directory. The compose file contains the service names and port mappings, but it does not by itself establish which environment variables or properties each Spring module expects.

For version selection, the README says that the source has been updated to Spring 7 and Spring Boot v4, while Spring Boot 3.x code is available under boot-3 and Spring Boot 2.x code is available under v1.0. This distinction is important because the repository's topic list includes older technologies and the README preserves historical directories. A reader who starts from a version-specific archive should expect a different dependency set from the default branch.

A practical first-use sequence is therefore to identify the desired module, choose the branch or tag matching its Spring Boot generation, read that module's own documentation and configuration files, and start only the services named by the example. This sequence avoids treating the default branch as a version-neutral package.

Security, Multipart, and Traditional Web Comparisons

The security section is substantial enough to affect adoption decisions. The README lists security, security-form, security-user-properties, security-method, and security-data-mongo. These modules cover basic reactive security, login forms, users stored in users.properties, method-level constraints instead of URI-based configuration, and Mongo-driven users. The security-data-mongo module is based on data-mongo and security, so it combines two infrastructure concerns rather than isolating them.

The security-method example is a notable comparison point. Replacing URI-based configuration with method-level constraints changes where access decisions are expressed. That can be useful for understanding authorization close to application operations, but it does not mean the two approaches are interchangeable without examining the sample's exact annotations and setup. The README does not document a complete authorization matrix or production deployment configuration.

The multipart and multipart-data-mongo examples add request and storage concerns. multipart handles multipart requests and file uploading. multipart-data-mongo combines multipart handling with GridFsTemplate storage in MongoDB. A file upload path is not automatically a small variation of a JSON endpoint: it introduces request parsing, content handling, storage behavior, and resource limits. The README does not specify file-size limits, error handling, or security restrictions for these examples, so those points require direct inspection before adoption.

The repository also includes traditional web modules using Thymeleaf and Mustache. Their presence is useful because reactive Spring projects are often compared with MVC applications. It does not establish that the MVC modules are production templates, nor does it provide a controlled performance comparison. The relevant comparison is architectural: WebFlux, functional routes, MVC, and template engines are presented as separate sample paths.

Limitations, Alternatives, and Maintenance Boundaries

The main limitation is that this is a sample repository, not a cohesive framework or application. Each module may target a different Spring generation, server, reactive library, datastore, or security arrangement. The README explicitly preserves separate Boot 2.x and Boot 3.x archives, while the source is described as Spring 7 and Spring Boot v4. That history creates a real upgrade decision rather than a purely technical curiosity. Code copied from one tag may not compile or behave as expected against another tag.

The repository is also silent about rollback procedures, production readiness, benchmark results, performance guarantees, and a supported compatibility matrix. It does not provide evidence that every sample is suitable for deployment. The docker-compose.yml is intended as a local service configuration, and its broad image tags and development credentials should not be mistaken for production operations. This is the wrong tool for any team requirement of a maintained application skeleton with one consistent dependency policy.

A real alternative is to use Spring Initializr for a single application and then consult this repository for focused examples of the relevant integration. Spring Initializr can be compared with the repository's many focused sample modules across reactive libraries and data stores. Another practical alternative is to choose one of the author's related projects when the requirement is specifically RSocket, Kotlin coroutines, Spring DSL, Angular integration, or R2DBC. Those repositories narrow the scope, while this repository exposes several choices in one place.

The repository is not archived. Its last push was on 2026-10-01, so it has recent repository activity, but that fact does not establish compatibility for every module. The project is licensed under GPL-3.0. Anyone copying substantial code into a proprietary or differently licensed product should review the license obligations and preserve required notices. That is a repository-specific licensing boundary, not a claim about suitability for a particular organization.

Editorial conclusion

Adopt this repository when you need working examples of Spring reactive APIs or want to compare Reactor with RxJava 3 and SmallRye Mutiny. Do not treat it as a production service, a dependency, or a complete reference for one reactive stack. Verify first which branch or tag matches your Spring Boot generation, whether the selected sample has the required backing service, and whether its configuration matches the API behavior you intend to use.

Frequently asked questions

Official sources

1. hantsy/spring-reactive-sample on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases