Akka or Reactor

I am in the process of starting a new project (java-based). I need to build it as a modular, distributed and resilient architecture.

Therefore I would like to have the business processes to communicate among themselves, be interoperable, but also independent.

I am looking right now at two frameworks that, besides their difference in age, express 2 different views:

• Akka (http://akka.io)
• Reactor (https://github.com/reactor/reactor)

What I should consider when choosing one of the above frameworks?

As far as I understand till now, Akka is still somehow coupled (in a way that I have to 'choose' the actor I want to send the messages to), but very resilient. While Reactor is loose (as is based on event posting).

Can someone help me understand how make a proper decision?

UPDATE

After reviewing better the Event Bus of Akka, I believe in some way the features expressed by Reactor are already included in Akka.

For example the subscription and event publishing, documented on https://github.com/reactor/reactor#events-selectors-and-consumers, can be expressed in Akka as following:

final ActorSystem system = ActorSystem.create("system");
final ActorRef actor = system.actorOf(new Props(
	new UntypedActorFactory() {

		@Override
		public Actor create() throws Exception {

			return new UntypedActor() {
				final LoggingAdapter log = Logging.getLogger(
						getContext().system(), this);

				@Override
				public void onReceive(Object message)
						throws Exception {
					if (message instanceof String)
						log.info("Received String message: {}",
								message);
					else
						unhandled(message);
				}
			};
		}
	}), "actor");

system.eventStream().subscribe(actor, String.class);
system.eventStream().publish("testing 1 2 3");

Therefore it seems to me now that the major differences between the two are:

• Akka, more mature, bound to Typesafe
• Reactor, early stage, bound to Spring

Is my interpretation correct? But what is conceptually the difference between the Actor in Akka and the Consumer in Reactor?

It is hard to tell at this point because Reactor is still a sketch and I (Akka tech lead) do not have insight into where it will go. It will be interesting to see if Reactor becomes a competitor to Akka, we are looking forward to that.

As far as I can see, from your requirements list Reactor is missing resilience (i.e. what supervision gives you in Akka) and location transparency (i.e. referring to active entities in a fashion which lets you abstract over local or remote messaging; which is what you imply by “distributed”). For “modular” I do not know enough about Reactor, in particular how you can look up active components and manage them.

If you start a real project now and need something which satisfies your first sentence, then I don’t think it would be controversial to recommend Akka at this point (as Jon also noted). Feel free to ask more concrete questions on SO or on the akka-user mailing list.

Reactor is not bound to Spring, it's an optional module. We want Reactor to be portable, a foundation as Jon outlined.

I won't be confident about pushing in production as we are not even Milestone (1.0.0.SNAPSHOT), in that regard, I would have a deeper look at Akka which is a fantastic asynchronous framework IMO. Also consider Vert.x and Finagle which might be adapted if you look either for a platform (the former) or for composable futures (the latter). If you look after a wide range of asynchronous patterns, maybe GPars will provide you a more complete solution.

In the end, we might certainly have overlaps, in fact we're leaning toward a mixed approach (flexible composable eventing, distributed, and not bound to any dispatching strategy) where you can easily find bits from RxJava, Vert.x, Akka etc. We are not even opinionated by the language choice, even if we are strongly committed to Groovy, people have already started Clojure and Kotlin ports. Add to this mix the fact that some requirements are driven by Spring XD and Grails.

Many thanks for your witnessed interest, hopefully you'll have more comparison points in a couple of months :)

This is an excellent question and the answer will change over the weeks to come. We can't make any promises of what inter-node communication will look like right now just because it's too early. We still have some pieces to put together before we can demonstrate clustering in Reactor.

With that said, just because Reactor doesn't do inter-node comms OOTB doesn't mean it can't. :) One would only need a fairly thin network layer to coordinate between Reactors using something like Redis or AMQP to give it some clustered smarts.

We're definitely talking about and planning for distributed scenarios in Reactor. It's just too early to say exactly how it's going to work.

If you need something that does clustering right now, you'll be safer choosing Akka.