Akka or reactor

Question

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

Therefore, I would like business processes to be interconnected, interoperable, but also independent.

I am looking right now at two frames that, in addition to their age difference, express two different opinions:

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

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

As far as I understand so far, Akka is still somehow combined (in such a way that I need to "choose" the actor to whom I want to send messages), but is very stable. While the reactor is free (as based on the publication of events).

Can someone help me figure out how to make the right decision?

UPDATE

After a better review of Akka's Event Bus , I somehow believe expressed Reactor is already included in Akka.

For example, the publication of a subscription and events, documented by https://github.com/reactor/reactor#events-selectors-and-consumers , can be expressed in Akka as follows:

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 that the main differences between them:

• Akka, more mature, Typesafe addicted
• Reactor, Spring's Early Stage

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

Answer 1

It's hard to say at this point, because Reactor is still a sketch, and I (Akka's lead specialist) have no idea where it will go. It will be interesting to see if Reactor becomes a competitor to Akka, we look forward to it.

As far as I can see, from your list of requirements, Reactor lacks stability (i.e., what control Akka gives you) and transparency of location (that is, referring to active objects in such a way that you can abstract from local or remote messages; this is what you mean by "distributed"). For "modular", I am not good at Reactor, in particular, how you can search for active components and manage them.

If you are starting a real project right now and need something that satisfies your first suggestion, then I don’t think it would be debatable to recommend Akka at that moment (as John noted). Feel free to ask more specific questions about SO or on the akka-user mailing list .

Answer 2

The reactor is not associated with Spring; it is an optional module. We want the reactor to be portable, the foundation, as John outlined.

I will not be sure to move into production, since we are not even Milestone (1.0.0.SNAPSHOT), in this regard I would look at Akka, which is a fantastic asynchronous IMO infrastructure. Also consider Vert.x and Finagle, which can be adapted if you look at either the platform (the former) or the composite futures (the latter). If you look at a wide range of asynchronous patterns, perhaps GPars will provide you with a more complete solution.

In the end, maybe we have overlaps, in fact we are inclined towards a mixed approach (flexible compound events, distributed and not related to any sending strategy), where you can easily find bits from RxJava, Vert.x, Akka etc. We are not even sure about the choice of language, even if we are strongly committed to Groovy, people have already launched the ports of Clojure and Kotlin. Add to this the confusion of the fact that some requirements are due to Spring XD and Grails .

Thank you very much for your proven interest, I hope you will have more milestones in a couple of months :)

Answer 3

This is a great question and the answer will change in the coming weeks. We cannot make any promises of the interface with which the message will be displayed right now, because it is too early. We still have a few parts to assemble before we can demonstrate clustering in the reactor.

With that said, just because Reactor doesn't do inter-node comms, OOTB doesn't mean it can't. :) You would need a thin enough network layer to coordinate between reactors, using something like Redis or AMQP to give him a few cluster smarts.

We definitely discuss and plan distributed scripts in Reactor. It's too early to say exactly how it will work.

If you need something that clusters right now, you'll be a safer choice for Akka.