В первой части мы узнали, что такое реактивность и как с ней работать на базовом уровне. Если вы хотите продолжить изучение реактивного программирования с новым фреймворком от Spring, то добро пожаловать!
Сейчас мы разберем, что делать с полученными знаниями из прошлой статьи, а также построим небольшой веб-сервис, который будет работать в асинхронном режиме.
Для этого нам понадобятся:
- База данных MongoDB. Дело в том, что далеко не все СУБД поддерживают асинхронную работу. MongoDB в этом смысле приятно отличается и полностью поддерживает нужный нам функционал.
- Драйвер для асинхронной работы с базой данных. Обычный драйвер так не умеет.
- Spring Boot 2. На данный момент Spring Boot находится в стадии разработки, но должен выйти 18 декабря. Он нам сильно облегчит работу и сэкономит много времени.
- Gradle.Будет использован в качестве системы сборки.
- Java 8. Да, это не последняя версия на данный момент, но для наших целей вполне подойдет.
- Lombok. Поможет сократить код.
Все настройки и финальный проект можно посмотреть на github.
Приступим
Если вы еще не подключили все зависимости, то можете сделать это прямо сейчас. В gradle выглядеть они будут так:
compile('org.springframework.boot:spring-boot-starter-data-mongodb-reactive') compile('org.springframework.boot:spring-boot-starter-webflux') compileOnly('org.projectlombok:lombok') testCompile('org.springframework.boot:spring-boot-starter-test') testCompile(‘io.projectreactor:reactor-test')
Итак, у нас все готово. Для начала создадим пользователя нашего приложения:
@Data @AllArgsConstructor @NoArgsConstructor @Document public class User { @Id private String id; private String firstName; private String lastName; }
Напоминаю, что для успешной компиляции и работы в IntelliJ Idea необходимо выставить галочку в пункте enable annotation processing либо написать самостоятельно все сеттеры, гетеры и конструкторы.
Далее создадим репозиторий с нашими пользователями:
import org.faoxis.habrreactivemongo.domain.User; import org.springframework.data.mongodb.repository.ReactiveMongoRepository; public interface UserRepository extends ReactiveMongoRepository<User, String> { }
Здесь следует заметить, что мы наследуемся от особого интерфейса для работы в реактивном режиме. Если заглянуть в интерфейс ReactiveMongoRepository, то можно увидеть, что нам возвращаются объекты, обернутые в уже знакомые нам классы Mono и Flux. Это значит, что при каком-либо обращении в БД, мы не получаем сразу же результат. Вместо этого мы получаем поток данных, из которого можно получить данные по мере готовности.
На данный момент многослойная архитектура является наиболее распространенным решением при работе с микросервисной архитектурой. Это действительно очень удобно. Давайте создадим сервисный слой. Для этого сделаем соответствующий интерфейс:
public interface UserService { Flux<User> get(); Mono<User> save(User user); }
Наш сервис достаточно прост, поэтому сразу создаем несколько полезных методов. И тут же реализуем их:
@Service @AllArgsConstructor public class UserServiceImpl implements UserService { private UserRepository userRepository; @Override public Flux<User> get() { return userRepository.findAll(); } @Override public Mono<User> save(User user) { return userRepository.save(user); } }
Здесь стоит заметить, что внедрение зависимости UserRepository происходит через конструктор с помощью аннотации AllArgsConstructor. На всякий случай напомню, что с некоторой версии Spring 4 можно осуществлять автоматическое внедрение зависимостей через конструктор без аннотации Autowire.
И, наконец, сделаем контроллер:
import lombok.AllArgsConstructor; import org.faoxis.habrreactivemongo.domain.User; import org.faoxis.habrreactivemongo.service.UserService; import org.springframework.web.bind.annotation.*; import reactor.core.publisher.Flux; import reactor.core.publisher.Mono; @RestController @RequestMapping("/users") @AllArgsConstructor public class UserController { private UserService userService; @PostMapping public Mono<User> post(@RequestBody User user) { return userService.save(user); } @GetMapping public Flux<User> get() { return userService.get(); } }
Запустим наше приложение. Все должно работать. Теперь сделаем POST запрос на localhost:8080/users со следующим содержимым:
{ "firstName": "Peter", "lastName": "Griffin" }
В ответ мы получим такой же объект, но с присвоенным ему id:
{ "id": "5a0bf0fdc48fd53478638c9e", "firstName": "Peter", "lastName": "Griffin" }
Отлично! Давайте сохраним еще пару пользователей и попробуем посмотреть, что у нас уже есть в БД. У меня такой результат GET запроса на localhost:8080/users:
[ { "id": "5a0bf0fdc48fd53478638c9e", "firstName": "Peter", "lastName": "Griffin" }, { "id": "5a0bf192c48fd53478638c9f", "firstName": "Lois", "lastName": "Griffin" }, { "id": "5a0bf19ac48fd53478638ca0", "firstName": "Mag", "lastName": "Griffin" } ]
Отлично! У нас есть целый сервис, который работает в асинхронном режиме! Но есть еще кое-что, о чем следует помнить. Работа с асинхронным репозиториями может очень сильно поменять вид сервиса, который получает данные из него.
Чтобы продемонстрировать это, создадим еще один обработчик URL метода в нашем контроллере:
@GetMapping("{lastName}") public Flux<User> getByLastName(@PathVariable(name = "lastName") String lastName) { return userService.getByLastName(lastName); }
Здесь все просто. Мы получаем фамилию пользователя и выводим всех людей с такой фамилией.
Конечно, такую логику можно возложить на базу данных, но здесь я хотел бы обратить внимание, как это будет выглядит в сервисе:
@Override public Flux<User> getByLastName(final String lastName) { return userRepository .findAll() .filter(user -> user.getLastName().equals(lastName)); }
Обратите внимание, что есть разница в работе с данными и потоками данных. Обычно мы осуществляем какие-то действия над данными непосредственно. Здесь ситуация другая. Мы говорим, что следует сделать в потоке данных.
Попробуем сделать GET запрос по URL localhost:8080/users/Griffin. У меня такой результат:
[ { "id": "5a0bf0fdc48fd53478638c9e", "firstName": "Peter", "lastName": "Griffin" }, { "id": "5a0bf192c48fd53478638c9f", "firstName": "Lois", "lastName": "Griffin" }, { "id": "5a0bf19ac48fd53478638ca0", "firstName": "Mag", "lastName": "Griffin" } ]
В этой статье мы рассмотрели, как построить асинхронный сервис с новым фреймворком WebFlux и сервером Netty (он идет из коробки по умолчанию). Также мы убедились, как легко этого достичь со Spring Boot 2. Если у вас на проекте микросервисная архитектура, то скорее всего вы легко сможете при желании перевести свои приложения на WebFlux с выходом Spring Boot 2(если, конечно, в этом есть потребность).
P.S. Есть несколько идей по продолжению. Если вам интересен материал, и вы не против моей подачи, то в следующих частях мы можем рассмотреть, например, асинхронное взаимодействие между приложениями. Спасибо за внимание!
