Asynchronous Processing Models in Services
Tags: reactive, functional, java, beginners
Published: 2019-09-30 11:57:48

---
title: Asynchronous Processing Models in Services
published: true
description: Search for convenient way to write asynchronous services
tags: #reactive #functional #java #beginners
---

Asynchronous processing is one of the topics of my interests for long time. I saw a lot of articles dedicated to this topic, but I newer saw any  article which would cover (at least briefly) most of them. I decided to try to fill this gap. Description below is quite brief, but tries to show at least basic properties of each model.

### Callbacks
This one is, probably one of the oldest and probably most widely used. The idea is obvious - configure __callback__ functions (often called __handler__) and it will be called when request arrives or some other event happens. There are a lot of uses of this model. Probably most famous one are earlier versions of **Node.js**. In Java world, older versions of [Vert.x](https://vertx.io/) is a great example of this model.

In code usually this model looks similar to following:

```java
    ... // Prepare request
    request.send(asyncResult -> {
      if (asyncResult.succeeded()) {
        System.out.println(asyncResult.result().body().getString("joke"));       
      }
    });

```

The lambda passed to `request.send` is a callback function, which is invoked when response on request is received.

Although this model looks simple, it has one huge drawback - callbacks are not composable. There is no simple way, for example, to create callback which will be invoked when two other callbacks were triggered. As a consequence, any more or less complex processing quickly turns into __callback hell__. 

### Reactive Streams 
This model is quite popular: implementations like [RxJava](http://reactivex.io/), [Project Reactor](https://projectreactor.io/), [Reactive Streams](http://www.reactive-streams.org/) are widely used. 

The idea behind this model is following: every source of incoming events/requests/data/etc. is represented as stream and then processing is assembled as pipeline which processes elements from that stream. The pipeline can be quite complex and can be composed from different streams.

The code usually looks like this:
```java
Observable.fromIterable(words)
 .zipWith(Observable.range(1, Integer.MAX_VALUE), 
     (string, count)->String.format("%2d. %s", count, string))
 .subscribe(System.out::println);
```

This model is extremely powerful and convenient. Nevertheless, complex processing streams might require some time to master and not always simple to grasp. Another disadvantage is that every source of data (including single values) should be represented as stream. This often might look artificial.

### Future
The __Future__ represents a result which might not be yet available, but will be available eventually:

```java
Future<Result> futureResult = executor.submit(() -> new Result("success"));
```
__Future__ is composable (although requires [quite a lot of ceremony](http://blog.teamlazerbeez.com/2009/04/29/java-completionservice/) ) but it's far from convenient. If you need to know when result is ready, you have no choice but just convert asynchronous processing into synchronous one by calling `Future.get()`. 

### Promises
At the high level __Promises__ can be thought as combination of __Futures__ and __callbacks__. When __Promise__ is get resolved (assigned value) callbacks are invoked automatically:
```java
...
Promise<User> getUserById(UUID userId);
...

getUserById(userId)
    .then(user -> System.out.println("User: " + user));
...

```
The callback function passed to `.then()` method will be invoked when __Promise__ will be resolved. There is no limitation to number of callbacks which can be added to __Promise__, so while instance is passed across various methods, they can add their own callbacks as necessary. If __Promise__ is already resolved by the time when new callback is added, the callback is invoked immediately. Every callback is invoked only once and only in context of one thread, so there are no synchronization issues to worry about.

__Promises__ are composable, code is quite simple to write and read. There are also no artificial representations of data. 

These properties of __Promises__ triggered (slow) switching to them in recent versions of [Vert.x](https://vertx.io/), although they look somewhat foreign there because callback-based API remains mostly unchanged, so __Promises__ are just wrappers for callbacks.

There is another implementation of __Promises__ present in JDK since Java 8 and called `CompletableFuture`. Must admit that this implementation is not a direct replacement for traditional __Promises__ - it's quite heavyweight and has inconvenient API.

## Instead of afterword
At present I'm working on the [library](https://github.com/siy/reactive-toolbox-core) which implements __Promises__ model in more lightweight and convenient to use form. 
To get a taste how code utilizing this library might look like:

```java
    public Promise<Either<? extends BaseError, UserDashboard>> userProfileHandler(final UUID userId) {
        return zipAll(userService.userProfile(userId), 
                      userService.followers(userId), 
                      articleService.articlesByUser(userId, Order.DESC), 
                      commentService.commentsByUser(userId, Order.DESC))
                .map(result -> result.mapSuccess(tuple -> tuple.map(UserDashboard::new)));
    }

```
The code above is just an example and library itself has version `0.1.0`, but it's already possible to write code this way using library in its current state.