Simple reactive REST API with Spring Webflux and MongoDB using Domain Driven Design
In the last time I’m taking course of reactive programming with Webflux. It’s great technology, that will be winning on popularity in the future. Why ? Because is much faster than classic (thread-per-request) approach.Today I will present you simple apllication which shows basics of Webflux, reactive MongoDB, Domain Driven Design. In the future blog posts I will deep deeper in individual topics. I’m begginer in the most of the them also we will learn together !
If you are proffesional developer and you find mistakes, or (oh no !) bugs in code – let me know in comment.
List of contents
- What is reactive programming ?
- What is Spring Webflux ?
- What is MongoDB ?
- What is domain driven design ?
- About project
- Domain layer
- Infrastructure layer
- Application layer
- Web layer
What is reactive programming?
It’s programming paradigm based on asynchronous data streams. What does it mean ? In our old, good Spring applications each request blocks one thread (thread by request approach) which is blocked till the response comes back. It’s not effective in many cases.
In reactive approach whole interaction is asynchronous. It is possible with help of event loop, which is continuously running non blocking thread that handles incoming requests. When client sends request it will be subscribed in event loop. Clients’s thread is unblocked again and when server sends response after finishing the task, it goes back through event loop which redirects it to client.
In the classic thread-per-request approach the thread is blocked till the whole set of data is processed.
What is Spring Webflux ?
Webflux is the Spring’s answer for need of reactive non-blocking frameworks. Instead of classic blocking Tomcat server which is used in Spring Boot by default, in Webflux non blocking Netty server helps us achieve all great capabilities of reactivity. The Spring Webflux is based on Project Reactor (https://projectreactor.io/), reactive library which implements Reactive Streams specification.
Webflux supports two programming models:
- Annotation based reactive components, which is similar to classic SpringMVC style.
- Functional routing and handling, which is based on router and handler functions (this approach is similar to routing in Node.js in design)
I prefer functional approach, it looks more modern for me, so i will use it in this project.
What is MongoDB ?
MongoDB is non relational database based on JSON documents (analogical to row in SQL Table). These Documents are the part of collection (table in SQL). The Mongo databases are very flexible and have great scalability – it’s working great with big amount of unstructured data.
I won’t go dive deep into Mongo internals in this post, because we don’t must. Spring Data offers great support for the main features and when you have some experience with Spring Data JPA it will be no problem for you.
What is domain driven design?
It’s approach in software development which is helpful by building large applications with complex business logic. The main idea is to design applications matching domain as most it is possible. DDD is set of ideas, patterns, techniques and best practices introduced in 2004 by Eric J. Evans in his famous book “Domain-Driven Design: Tackling Complexity in the Heart of Software”.
Everything in application (from database to domain objects) should be named with language specific for the business (in DDD called ubiquitous language), as less technical as it is possible. It means that the understanding of the code without knowing the domain is impossible.
In projects where DDD is used the developers are working in team together with domain experts (often without technical knowledge) which are active members of development process.
The core domain should be free from any frameworks or external dependencies and in theory is technology independent.
Modeling of the domain is the base by projecting of application in this approach. The quality of modelling will be crucial in the future, when the application grows and become more complex.
DDD introduces some patterns which help us in proper modelling of the domain. The most of them are not used in this project, because it is really simple.
The most important pattern is called bounded context. It splices our application into independent parts of domain entities that have boundary around common business cases.
Another patterns of DDD are at example:
- Aggregate root
- Domain entity
- Value object
I don’t describe it here, because details of domain driven design approach are not the main target of this post. I will cover some interesting topics from domain driven design area in the next future. Be aware ! 🙂
About project
Today I will code very simple reactive timesheet with time entries of user which belongs to team. I don’t want cover complex business rules here – my target is to show how you can implement relations in MongoDB (unfortunately for correct results of cascading we must make it manually) and how design reactive Rest API with Spring Webflux.
In this post I won’t paste whole codebase, only some examples. Whole code you can find on GitHub – https://github.com/szymon-sawicki/reactive-timesheet-app
I use Java 17, Spring Boot, WebFlux, Reactive MongoDB and Lombok. That are the dependencies needed today:
At first i will describe application’s name in <build> section of POM.XML. It’s create friendly name of JAR package, it makes creating docker container little bit easier.
|
1 |
<finalName>app</finalName> |
Our app will be started in docker container together with instance of MongDB. At first the Dockerfile need to be created:
|
1 2 3 4 |
FROM openjdk:17 EXPOSE 8080 ADD target/app.jar app.jar ENTRYPOINT ["java","-jar","app.jar"] |
docker-compose.yml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
version: '3.8' services: mongodb: image: mongo:latest container_name: "mongodb" ports: - "27017:27017" reactive-timesheet-app: image: reactive-timesheet-app build: context: . dockerfile: Dockerfile depends_on: - mongodb ports: - "8080:8080" |
Yet it’s time for some configuration, let’s look into application.yml
|
1 2 3 4 5 6 7 8 |
spring: application: name: reactive-timesheet-app data: mongodb: database: db_1 host: mongodb port: 27017 |
Let make our hands dirty with some code. I’m starting with package structure, I use Domain Driven Design approach with three main layers:
- application – depends on domain and infrastructure layers. We are implementing here most of our business logic.
- domain – doesn’t depend on any layer. Contains the heart of the app – domain objects with some utility classes, dto’s and repository interfaces. Any kind of framework is here not allowed.
- infrastructure – depends on domain layer. Here takes place whole interaction with database (reactive MongoDB in our case)
- web – depends on application layer. Contains handlers and routing for reactive REST API.
That is the package structure of app:
Domain layer
In next step i will create heart of our application – domain objects. In this case only three – User, Team and TimeEntry. All member fields of our domain objects have package-private visibility so we can achieve immutability and encapsulation, for the extern access to some fields I create utility class in the same package with Function taking object and returning needed field
|
1 2 3 4 5 6 |
public interface UserUtils { Function<User, String> toId = user -> user.id; Function<User, String> toUsername = user -> user.username; Function<User, String> toTeamId = team -> team.teamId; } |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
@AllArgsConstructor @NoArgsConstructor @Builder @EqualsAndHashCode public class Team { String id; String name; List<User> members; //... methods used for modification of the fields and mappers } |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
@AllArgsConstructor @NoArgsConstructor @Builder @EqualsAndHashCode public class TimeEntry { String id; LocalDateTime timeFrom; LocalDateTime timeTo; User user; //... methods used for modification of the fields and mappers } |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@AllArgsConstructor @NoArgsConstructor @Builder @EqualsAndHashCode public class User { String id; String username; String password; Role role; String teamId; //... methods used for modification of the fields and mappers } |
To make modification of some fields possible I created methods returning objects with new values. Example:
|
1 2 3 4 5 6 7 8 9 |
public User withTeamId(String newTeamId) { return User.builder() .id(id) .username(username) .password(password) .role(role) .teamId(newTeamId) .build(); } |
Examples of the mappers, made with the help of builder design pattern
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
public TeamEntity toEntity() { return TeamEntity.builder() .id(id) .name(name) .members(members) .build(); } public GetTeamDto toGetTeamDto() { return new GetTeamDto( id, name, members.stream().map(User::toGetUserDto).toList()); } } |
To determine operations which be needed in our business logic I create repository interfaces in each domain package. They all have some common methods, this methods I will extract to separate class – CrudRepository, it can be found in configs package and each specific repository interface extends it.
|
1 2 3 4 5 6 7 8 9 |
public interface CrudRepository<T, ID> { Flux<T> findAll(); Flux<T> findAllById(List<ID> ids); Mono<T> findById(ID id); Mono<T> save(T t); Mono<T> delete(ID id); } |
Example of the repository:
|
1 2 3 4 5 6 7 8 9 |
public interface UserRepository extends CrudRepository<User, String> { Flux<User> findByTeamId(String teamId); Mono<User> findByUsername(String username); Flux<User> saveAll(List<User> users); Mono<Void> deleteAll(List<User> users); } |
Infrastructure layer
After that i will go to infrastructure layer and dive into persistence part. All domain classes are represented by entities, which are decorated with Spring Data MongoDB annotations. Each of them have also own mapper that converts entity into domain object. Example:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
@Document(collection = "time_entries") @Builder @Getter @NoArgsConstructor @AllArgsConstructor public class TimeEntryEntity { @Id String id; LocalDateTime timeFrom; LocalDateTime timeTo; UserEntity user; Category category; String description; public TimeEntry toTimeEntry() { return TimeEntry.builder() .id(id) .timeFrom(timeFrom) .timeTo(timeTo) .user(user.toUser()) .category(category) .description(description) .build(); } } |
The DAO is the lowest layer in persistence, it is responsible for direct communication with database. Each DAO interface extends Spring’s ReactiveMongoRepository, which is similar to classic JpaRepository and provide rich set ready to use methods, we have also possibility to create own implementations using natural language or custom queries Criteria, or JSON Queries. In my project I use some generated method using natural language.
|
1 2 3 4 |
public interface TeamDao extends ReactiveMongoRepository<TeamEntity, String> { Mono<TeamEntity> findByName(String name); } |
|
1 2 3 4 |
public interface TimeEntryDao extends ReactiveMongoRepository<TimeEntryEntity, String> { Flux<TimeEntryEntity> findAllByUser(UserEntity user); } |
|
1 2 3 4 |
public interface UserDao extends ReactiveMongoRepository<UserEntity,String> { Flux<UserEntity> findByTeamId(String teamId); Mono<UserEntity> findByUsername(String username); } |
On the top of DAOs I will introduce implementations of earlier created repositories, which are separating db of our business logic and will be used in services. The DAOs are injected here and implementations of repository methods are converting entities into our domain objects. Whole data is wrapped in Webflux data types and conversion takes place i Inside flatMap method, so we keeping all benefits of reactive programming. Remember, that the most conversion and asynchronous operations should be done in flatMap() method, because map() breaks the flow and works synchronous (blocking thread).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
@Repository @RequiredArgsConstructor public class TimeEntryRepositoryImpl implements TimeEntryRepository { private final TimeEntryDao timeEntryDao; @Override public Flux<TimeEntry> findAll() { return timeEntryDao.findAll() .flatMap(timeEntry -> Mono.just(timeEntry.toTimeEntry())); } @Override public Flux<TimeEntry> findAllById(List<String> ids) { return timeEntryDao.findAllById(ids) .flatMap(timeEntry -> Mono.just(timeEntry.toTimeEntry())); } @Override public Mono<TimeEntry> findById(String id) { return timeEntryDao.findById(id) .flatMap(timeEntry -> Mono.just(timeEntry.toTimeEntry())); } @Override public Mono<TimeEntry> save(TimeEntry timeEntry) { return timeEntryDao.save(timeEntry.toEntity()) .flatMap(timeEntryEntity -> Mono.just(timeEntryEntity.toTimeEntry())); } @Override public Mono<TimeEntry> delete(String id) { return timeEntryDao.findById(id) .flatMap(timeEntryEntity -> timeEntryDao.delete(timeEntryEntity) .then(Mono.just(timeEntryEntity.toTimeEntry()))) .switchIfEmpty(Mono.error(new PersistenceException("cannot find team to delete"))); } @Override public Flux<TimeEntry> findAllByUser(User user) { return timeEntryDao.findAllByUser(user.toEntity()) .flatMap(timeEntryEntity -> Mono.just(timeEntryEntity.toTimeEntry())); } } |
Application layer
Ok, our db layer is ready and waiting for the job. Yet is time for may favorite part with lot of meat – services, which are called in handlers in web layer. I don’t want cover all CRUD operations here – for our purposes I will create some basic functionalities like creating, deleting finding by name and id methods. We have some relationships between domain objects and I will show you have we can implement it with the MongoDB in functional manner using Webflux. In each service I used @Slf4j annotation from Lombok for automatic logger generation. Data access provides repositories, which are injected with constructor (also generated with Lombok).
In service layer data is also wrapped into reactive types, but here inside reactive streams you can find only Data Transfer Objects, which are used in communication with the web layer. I’m starting with UserService – it will containing 4 public methods – findById, findByUsername, addUser and deleteUser. Two first methods are simple – after call of repository we are mapping result into dto, in this case I use map() method, because I don’t make any further operations and the result will be showed to the user. For the exception handling I use switchIfEmpyMethod() which be called if the result of the earlier operations is empty (not found in db). I’m generating here exception of my custom type wrapped in Mono.
By creating of the user at first we must check, if the user with the given username already exists in the DB. If user with given username were found I log message on the error debugging level and return existing user with that username.If result previous operation is empty, we can insert out user into db – I call switchIfEmpty method where I save new user and the map the result to dto.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 |
@Service @Slf4j @RequiredArgsConstructor public class UserService { private final TeamRepository teamRepository; private final UserRepository userRepository; public Mono<GetUserDto> findById(String userId) { return userRepository.findById(userId) .map(User::toGetUserDto) .switchIfEmpty(Mono.error(new UserServiceException("id doesn't exist"))); } public Mono<GetUserDto> findByUsername(String username) { return userRepository.findByUsername(username) .map(User::toGetUserDto) .switchIfEmpty(Mono.error(new UserServiceException("username doesn't exist"))); } public Mono<GetUserDto> addUser(Mono<CreateUserDto> createUserDtoMono) { return createUserDtoMono .flatMap(createUserDto -> userRepository .findByUsername(createUserDto.username()) .hasElement() .flatMap(isUserPresent -> isUserPresent ? Mono.error(new UserServiceException("user with username " + createUserDto.username() + " already exists")) : createUser(createUserDto))); } private Mono<GetUserDto> createUser(CreateUserDto createUserDto) { var user = createUserDto.toUser(); return userRepository .save(user) .map(User::toGetUserDto); } public Mono<GetUserDto> deleteUser(String userId) { return userRepository .findById(userId) .flatMap(user -> userRepository.delete(userId) .then(deleteMemberFromTeam(user))) .switchIfEmpty(Mono.error(new UserServiceException("cannot find user to delete"))); } private Mono<GetUserDto> deleteMemberFromTeam(User member) { var teamId = UserUtils.toTeamId.apply(member); if (teamId != null) { return teamRepository .findById(teamId) .flatMap(team -> { TeamUtils.toMembers.apply(team).remove(member); return teamRepository.save(team) .flatMap(t -> Mono.just(member.toGetUserDto())); }) .switchIfEmpty(Mono.error(new UserServiceException("cannot find user's team"))); } return Mono.just(member.toGetUserDto()); } } |
The next service will be much more interesting, because here comes first relationship. Our team have list of members i must have one user with lead role. In MongoDb for proper implementation of relationships we must solve it manually like in old good times before ORM in SQL 🙂 Good practice is to have object on one side of relationship and id on the other. Our team have list of user objects and user have team id. Both classes have inside utility method which are creating new object with updated list of members by team or teamId by user.
After two boring findBy… methods (equal to methods from user) I am creating addTeam() method, which also like by user at first checks if team with given name exists and then (if result is empty) calls private helper method “createTeamWithMembers()”. Here we have some fun, at first new team must be inserted into db, then all new members must be saved (with saveAll() method) into db with new generated id of the team. After that we are updating list with members of team and save team with actual members data into db. All that is made inside flatMap method.
The last method in this service id deleteTeam(), here also we must take care of proper cascading to achieve consistency of data. At first I get list of all team’s member and then with helper methods change teamId to null. After that all updated members are saved in and team is deleted.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 |
@Service @Slf4j @RequiredArgsConstructor public class TeamService { private final TeamRepository teamRepository; private final UserRepository userRepository; public Mono<GetTeamDto> findById(String teamId) { return teamRepository.findById(teamId) .map(Team::toGetTeamDto) .switchIfEmpty(Mono.error(new TeamServiceException("id doesn't exist"))); } public Mono<GetTeamDto> findByName(String name) { return teamRepository.findByName(name) .map(Team::toGetTeamDto) .switchIfEmpty(Mono.error(new TeamServiceException("Username doesn't exist"))); } public Mono<GetTeamDto> addTeam(Mono<CreateTeamDto> createTeamDtoMono) { return createTeamDtoMono .flatMap(createTeamDto -> teamRepository.findByName(createTeamDto.name()) .map(team -> { log.error("Team with name " + createTeamDto.name() + " already exists"); return team.toGetTeamDto(); }) .switchIfEmpty(createTeamWithMembers(createTeamDto)) ); } private Mono<GetTeamDto> createTeamWithMembers(CreateTeamDto createTeamDto) { // at first team is inserted into db and all its member are updated with the new teamId return teamRepository .save(createTeamDto.toTeam()) .flatMap(insertedTeam -> { var membersToInsert = createTeamDto .members() .stream() .map(createUserDto -> createUserDto.toUser().withTeamId(TeamUtils.toId.apply(insertedTeam))) .toList(); // then all members with correct teamId are saved into db, flux is converted to list which is used to update team's members. At the end updated team is saved in db. return userRepository .saveAll(membersToInsert) .collectList() .flatMap(insertedUsers -> teamRepository .save(insertedTeam.withMembers(insertedUsers)) .map(Team::toGetTeamDto)); }); } public Mono<GetTeamDto> deleteTeam(String teamId) { return teamRepository .findById(teamId) .flatMap(team -> { // at first, I'm changing teamId of all team members to null var membersToUpdate = TeamUtils.toMembers.apply(team) .stream() .map(member -> member.withTeamId(null)) .toList(); // then I'm saving all updated members, deleting team and returning mono of DTO return userRepository.saveAll(membersToUpdate) .then(teamRepository.delete(teamId)) .then(Mono.just(team.toGetTeamDto())); }) .switchIfEmpty(Mono.error(new TeamServiceException("cannot find team to delete"))); } } |
The last service care about time entries, here I will implement some simple methods for getting time entries and one for creating these. We don’t have here many extraordinary things, the time entry collision check I will implement in the next future. It doesn’t works properly.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
@Service @Slf4j @RequiredArgsConstructor public class TimeEntryService { private final TimeEntryRepository timeEntryRepository; private final UserRepository userRepository; public Mono<GetTimeEntryDto> addTimeEntry(Mono<CreateTimeEntryDto> createTimeEntryDtoMono) { return createTimeEntryDtoMonoTe .flatMap(this::checkEntry) .flatMap(createTimeEntryDto -> timeEntryRepository.save(createTimeEntryDto.toTimeEntry()) .map(TimeEntry::toGetTimeEntryDto)); } private Mono<CreateTimeEntryDto> checkEntry(CreateTimeEntryDto timeEntryToCheck) { return userRepository .findById(timeEntryToCheck.user().id()) .hasElement() .flatMap(isUserPresent -> isUserPresent ? findCollisions(timeEntryToCheck) : Mono.error(new UserServiceException("user not exists"))); } private Mono<CreateTimeEntryDto> findCollisions(CreateTimeEntryDto timeEntryToCheck) { // TODO proper implementation of collision check (doesn't work at the moment). Create isAvailable() method in TimeEntry domain class return timeEntryRepository.findAllByUser(timeEntryToCheck.user().toUser()) .filter(entry -> !TimeEntryUtils.toTimeFrom.apply(entry).isAfter(timeEntryToCheck.timeTo()) && !TimeEntryUtils.toTimeTo.apply(entry).isBefore(timeEntryToCheck.timeFrom())) .collectList() .flatMap(result -> { if (result.isEmpty()) { Mono.error(new TimeEntryServiceException("time entry collision")); } return Mono.just(timeEntryToCheck); }); } } |
Web layer
Our application layer is ready, we can go to web layer, which is really interesting in functional approach of Webflux. The endpoints are defined in router functions, which can be nested. The paths and other properties are build in builder style with RequestPredicates class (in examples below I used static import, to achieve good readability). With RequestPredicates.nest() method we can define main path in first argument and with chain of routing functions this path’s all endpoints.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
@Configuration public class Routing { @Bean public RouterFunction<ServerResponse> routingFunction(TeamHandlers teamHandlers, TimeEntryHandlers timeEntryHandlers, UserHandlers userHandlers) { return RouterFunctions.nest( // first argument of the router function is a request predicate, second - handler function path("/teams"), RouterFunctions.route(GET("/{name}").and(accept(MediaType.APPLICATION_JSON)), teamHandlers::findByName) .andRoute(GET("/id/{id}").and(accept(MediaType.APPLICATION_JSON)), teamHandlers::findById) .andRoute(POST("/").and(accept(MediaType.APPLICATION_JSON)), teamHandlers::addTeam) .andRoute(DELETE("/{id}").and(accept(MediaType.APPLICATION_JSON)), teamHandlers::deleteTeam)) .andNest(path("/users"), RouterFunctions.route(GET("/id/{id}").and(accept(MediaType.APPLICATION_JSON)), userHandlers::findById) .andRoute(GET("/{username}").and(accept(MediaType.APPLICATION_JSON)), userHandlers::findByUsername) .andRoute(POST("/").and(accept(MediaType.APPLICATION_JSON)), userHandlers::createUser) .andRoute(DELETE("/{id}").and(accept(MediaType.APPLICATION_JSON)), userHandlers::deleteUser)) .andNest(path("/time-entries"), RouterFunctions.route(POST("/").and(accept(MediaType.APPLICATION_JSON)), timeEntryHandlers::addTimeEntry)); } } |
All handlers have common parts and I extracted it to generic utility class GlobalRoutingHandler, which takes action (Mono) and http status as arguments. This class generates proper response with HTTP status and implements simple error handling.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
public interface GlobalRoutingHandler { // Helper method for generic request processing and error handling static <T> Mono<ServerResponse> doRequest(Mono<T> action, HttpStatus httpStatus) { return action .flatMap(result -> ServerResponse .status(httpStatus) .contentType(MediaType.APPLICATION_JSON) .body(BodyInserters.fromValue(result)) ) .onErrorResume(error -> ServerResponse .status(HttpStatus.INTERNAL_SERVER_ERROR) .contentType(MediaType.APPLICATION_JSON) .body(BodyInserters.fromValue(new ErrorDto(error.getMessage()))) ); } } |
Each chained endpoint is new router function, in first argument we are creating endpoint properties (http method with path and variable, accepted data type), second argument is handler function which processes the request. We can implement it here with lambda function, but good practice in real life projects is to create separate classes with handlers. I looks much better, because we cann call handler with simple method reference.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
@Component @RequiredArgsConstructor public class TeamHandlers { private final TeamService teamService; public Mono<ServerResponse> findById(ServerRequest serverRequest) { var teamId = serverRequest.pathVariable("id"); return GlobalRoutingHandler.doRequest(teamService.findById(teamId), HttpStatus.OK); } public Mono<ServerResponse> findByName(ServerRequest serverRequest) { var teamName = serverRequest.pathVariable("name"); return GlobalRoutingHandler.doRequest(teamService.findByName(teamName), HttpStatus.OK); } public Mono<ServerResponse> addTeam(ServerRequest serverRequest) { var createTeamDtoMono = serverRequest.bodyToMono(CreateTeamDto.class); return GlobalRoutingHandler.doRequest(teamService.addTeam(createTeamDtoMono), HttpStatus.CREATED); } public Mono<ServerResponse> deleteTeam(ServerRequest serverRequest) { var teamId = serverRequest.pathVariable("id"); return GlobalRoutingHandler.doRequest(teamService.deleteTeam(teamId), HttpStatus.OK); } } |
Handler function accepts ServerRequest as argument and returns Mono with result of our action. In this method we resolve path variables, query parameters, or request body and call right service to do action. Result is wrapped into response and mono.
Ok, reactive timesheet app looks ready. But it works ? Let ask mr. Postman ! In GitHub repository you can find postman collection with some prepared requests. But remember – in some cases you must pass the proper id in header!
As we see everything works fine, we can look for next challenges in fascinating world of reactive programming !
What next ?
Our adventure with reactive timesheet app is not finished. Every good application must be covered with tests ! In the next post I will show how you can write integration and unit tests in Webflux.