Akka or Reactor

Question

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?

Akka is not bound to be used by Scala, in fact, a majority use it from Java. — Viktor Klang, May 17 '13 at 11:57
Hello Viktor, yes, I'm using Akka with Java as well. What I meant is that Akka is part of the Typesafe ecosystem, whereas Reactor to Spring. When developing in Scala though, Akka would probably be the most appropriated choice. — David Riccitelli, May 17 '13 at 12:14
Viktor, I believe we could say that Akka implements the Reactor pattern (with the Event Bus, Dispatchers and Mailboxes), am I correct? — David Riccitelli, May 17 '13 at 13:07
David: Something like: Akka EventBus API in concert with Akka Actors implement the Reactor Pattern — Viktor Klang, May 17 '13 at 14:34
Just to clarify: Reactor isn't bound to Spring at all. We intentionally keep out any Spring dependencies because, as a foundational framework, it doesn't make sense to restrict its use to only Spring users. As for the difference between an Actor and a Consumer: as far as Reactor is concerned, your Consumer can be stateful or not. It's assumed that you'll want to use a stateless anonymous class or Java 8 lambda but that's not a requirement. And like I mentioned in my answer, the Reactor toolset is, for early iterations, intentionally succinct. We're not trying to create "the next Akka". — Jon Brisbin, May 21 '13 at 15:35
Just dropping a mention of http://vertx.io/ as I believe it to be in the same event driven field with some interesting concepts in similar vein for those who are researching.. — Opentuned, Aug 18 '14 at 12:28
Moving on a couple of years, I am also in a similar situation, My application is primarily a spring based and I now need handle an event driven feature. Is there a clear winner b/w Akka and Spring-reactor? I am looking for a framework with active user-communites in case I reach more complicated scenarios. — tintin, Jul 26 '15 at 08:20

score 49 · Answer 1 · answered May 21 '13 at 07:00

49

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.

answered May 21 '13 at 07:00

Roland Kuhn

15,412
2
36
45

Thanks Roland, I love to see that people from both projects are contributing to the answer. I am currently trying out Akka. As you anticipated, it's quite premature to provide a final answer to the question, except that Reactor is still in early stages, therefore not yet suitable for a comparison. So, let's wait and see how things evolve :-) Thanks, David – David Riccitelli May 21 '13 at 11:37
7

Thanks for your answer, Roland. I just wanted to clarify that Reactor is not an Akka competitor. There are similarities due to an overlapping area of concern regarding asynchronous applications. But Reactor is meant to be a foundational framework upon which other systems can be built. Those other systems might overlap even more with Akka than Reactor itself does. But for the foreseeable future Reactor will remain a framework that enables other systems and will not be itself a full-stack framework. You'll have to delay gratification on the Reactor/Akka shootout. ;) – Jon Brisbin May 21 '13 at 15:42
No worries, I think you’ll do fine, and I’m quite certain that we will see cross-pollination as more libraries enter this field. – Roland Kuhn May 21 '13 at 17:26
I think Spring Webflux has become a competitor as of now in 2023 – arqam Feb 08 '23 at 01:09

score 38 · Answer 2 · edited Oct 08 '17 at 21:04

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 :)

Thanks Stephane, I believe your answer (and Jon's comment, http://stackoverflow.com/questions/16595393/akka-or-reactor/16674388#comment23991745_16663953) give a much clearer perspective. I'll still hold before marking the question answered, as you said, let's see what pops out in the near future. Again I really appreciate that people involved in both projects spent time providing useful insights. — David Riccitelli, May 22 '13 at 12:44
I'd agree with Vert.x. I had used Vert.x in production environment in a couple of project to communicate between components and it works seamlessly. — Wins, Jan 02 '17 at 19:57

score 34 · Answer 3 · answered May 16 '13 at 20:38

34

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.

answered May 16 '13 at 20:38

Jon Brisbin

1,299
8
11

Thanks Jon, I find Reactor very promising. Yet I need to understand if there is a conceptual difference between Reactor and Akka, besides features that Reactor is missing (of course, being at its early stage). In summary what is the conceptual difference between an Actor in Akka and a Consumer in Reactor? I also updated my question with a sample Event in Akka which I believe resembles the event subscription/dispatching on the Reactor GitHub page. Thanks. – David Riccitelli May 17 '13 at 08:40
Jon, I was reading your response here: http://blog.springsource.org/2013/05/13/reactor-a-foundation-for-asynchronous-applications-on-the-jvm/#comment-345867 - so we might assume that in the long run Akka and Reactor will be similar framework, both supporting the Reactor pattern and the Actor model. – David Riccitelli May 20 '13 at 15:18
The above comment is no more correct due to the following: http://stackoverflow.com/questions/16595393/akka-or-reactor/16674388#comment23991745_16663953 and http://stackoverflow.com/a/16674388/565110 – David Riccitelli May 22 '13 at 12:38
I don't understand how this comment is now incorrect? Nothing here contradicts with the explanation of the strategic direction of Reactor. – Jon Brisbin May 23 '13 at 13:57
Hello Jon, given the information so far gathered, the sentence in my previous comment: 'we might assume that in the long run Akka and Reactor will be similar framework, both supporting the Reactor pattern and the Actor model' I think is no more correct. That sentence would be a restrictive definition of Reactor because, as you said earlier, 'We're not trying to create "the next Akka"' and 'your Consumer can be stateful or not'. Did I understand correctly? – David Riccitelli May 23 '13 at 14:08
1

Gotcha. Yes, you understand correctly. Thanks for asking these questions! :) – Jon Brisbin May 24 '13 at 15:03

Akka or Reactor

3 Answers3

Linked