101

I've worked with Node.js for a little while and consider myself pretty good with Java. But I just discovered Akka and was immediately interested in its actor pattern (from what I understand).

Now, assuming my JavaScript skills were on par with my Scala/Java skills, I want to focus on the practicality of either system. Especially in the terms of web services.

It was my understanding that Node is excellent at handling many concurrent operations. I imagine a good Node web service for an asset management system would excel at handling many users submitting changes at the same time (in a large, heavy traffic application).

But after reading about the actors in Akka, it seams it would excel at the same thing. And I like the idea of reducing work to bite-sized pieces. Plus, years ago I dabbled in Erlang and fell in love with the message passing system it uses.

I work on many applications that deal with complex business logic and I'm thinking it's time to jump heavier into one or the other. Especially upgrading legacy Struts and C# applications.

Anyway, avoiding holy wars, how are the two systems fundamentally different? It seems both are geared towards the same goal. With maybe Akka's "self-healing" architecture having an advantage.

EDIT

It looks like I am getting close votes. Please don't take this question as a "which is better, node or akka?". What I am looking for is the fundamental differences in event driven libraries like Node and actor based ones like Akka.

cbmeeks
  • 11,248
  • 22
  • 85
  • 136
  • @cbmeeks may I ask what did you choose and how is it going for you with your choice? – Jas Jun 28 '15 at 12:08

3 Answers3

72

Without going into the details (about which I know too little in the case of Node.js), the main difference is that Node.js supports only concurrency without parallelism while Akka supports both. Both systems are completely event-driven and can scale to large work-loads, but the lack of parallelism makes it difficult in Node.js (i.e. parallelism is explicitly coded by starting multiple nodes and dispatching requests accordingly; it is therefore inflexible at runtime), while it is quite easy in Akka due to its tunable multi-threaded executors. Given small isolated units of work (actor invocations) Akka will automatically parallelize execution for you.

Another difference of importance is that Akka includes a system for handling failure in a structured way (by having each actor supervised by its parent, which is mandatory) whereas Node.js relies upon conventions for authors to pass error conditions from callback to callback. The underlying problem is that asynchronous systems cannot use the standard approach of exceptions employed by synchronous stack-based systems, because the “calling” code will have moved on to different tasks by the time the callback’s error occurs. Having fault handling built into the system makes it more likely that applications built on that system are robust.

The above is not meant to be exhaustive, I’m sure there are a lot more differences.

Roland Kuhn
  • 15,412
  • 2
  • 36
  • 45
  • 2
    Do you think it is best way to use PLAY-FRAMEWORK or SPRAY if I decide to use AKKA to build restful web application? – ses Oct 16 '13 at 17:33
  • 4
    Yes, both are good choices. Play is suitable as a framework which gives you a fully integrated development experience, but it means that Play will be running your application. Spray is better if you want to just have a thin REST layer embedded in your Akka application. Please note that Spray will become akka-http in the next months. – Roland Kuhn Oct 16 '13 at 20:48
  • No, there is barely enough time to cover actors themselves, this would be a good topic for a sequel to that course. – Roland Kuhn Oct 17 '13 at 04:04
  • 3
    And also to point out, you get all the goodness of a statically typed language with Scala/Java and no callback hell in javascript. Java/Scala would be easier to debug than javascript. – Chirdeep Tomar Dec 09 '13 at 19:58
  • 2
    In terms of parallelism with node it should be mentioned that you can fork processes at runtime with its [cluster](http://nodejs.org/api/cluster.html) core API. It'll do what you mean by parallel actors. – kernel Apr 30 '14 at 13:33
  • 1
    Node.js apps could also implement parallelism through webworkers see https://www.npmjs.org/package/webworker-threads – AsTeR Jun 13 '14 at 13:48
  • 2
    It seems to me this answer from 2012 is now very dated since many many things have changed especially with Node since them. Look at https://www.npmjs.com/package/webworker-threads web workers in Node, you can move blocking intesive work to a parrellel process (all while in the same Node process). – Mark Pieszak - Trilon.io Dec 29 '15 at 15:38
  • this answer is just incorrect...node.js uses Libuv for I/O. Libuv uses a threadpool for both async I/O and sync I/O. – Alexander Mills May 10 '17 at 00:03
  • @AsTeR the point with nodejs is that is not mature enough, akka provide already everything. In node you need to search or build your own npm package and still is not so powerful, basically can run on a single thread only, but you will say: there is pm2 to do over and so on. The point is, the design of nodejs is not the same of akka, it is a quite immature compare to akka. good for pet project or micro-service though. – Raffaello Sep 03 '18 at 09:00
  • 1
    To put it simply, Akka can easily build Node.JS (and run single threaded if that was desired), but the converse is not true. Plus, the error management is much superior. Therefore, Akka is a superset, and much more powerful than Node.JS. Akka Streams are even more powerful, and so is Akka HTTP. – fracca Mar 16 '19 at 15:26
9

I didn't yet use Akka, but it seems it's erlang-like but in java. In erlang all processes are like actors in Akka, they have mailboxes, you can send messages between them, you have supervisors etc.

Node.js uses cooperative concurrency. That means you have concurrency when you allow it (for example when you call io operation or some asynchronous event). When you have some long operation (calculating something in long loop) whole system blocks.

Erlang uses preemptive task switching. When you have long loop, system can pause it to run other operation and continue after some time. For massive concurrency Node.js is good if you do only short operations. Both support millions of clients: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/

In java you need threads to do any concurrency, otherwise you can't pause execution inside function which erlang does (actually erlang pauses between function calls, but this hapens with all functions). You can pause execution between messages.

yetihehe
  • 620
  • 8
  • 11
  • OK, so assuming I need to record log files from many different sources. Each time an application generates a log entry, I also need to send that entry to another application for recording. I assume this could be a long running process because the app could have DB timeouts, http failures, etc. So in this example, a hang in writing to the DB would cause my entire Node system to hang? Would AKKA suffer the same issue or am I just not getting the correlation? – cbmeeks Dec 17 '12 at 18:49
  • 1
    Neither would suffer, because db access is typically implemented as asynchronous in such cases. But if you somehow managed to make synchronous library doing that, they would both freeze. – yetihehe Dec 17 '12 at 18:51
  • Thanks. I'm trying very hard not to turn this into a `node vs akka` debate but I have a real problem I need to solve. I would say my Java/JavaScript skills are pretty close but I have very little experience with Node and none with AKKA (or Scala). But I have several applications (internal for now but external later) and people are looking for ways to search these massive logs. Can't use external 3rd party options due to privacy issues. Seems that either would handle the job. But I like the message passing of AKKA so I might explore that. Plus Java is pushed more here than JS. Thanks. – cbmeeks Dec 17 '12 at 19:04
  • If you need searching of massive logs, try looking at logstash or graylog2. – Toddius Zho Aug 08 '13 at 14:47
6

I'm not sure this is a fair comparison to draw. I read this more as "how does an evented based system compare with an actor model?". Nodejs can support an actor model just as Scala does in Akka, or C# does in Orleans, in fact check out nactor, somebody appears to already be trying it.

As for how an evented system vs. actor model compare, I would let wiser people describe it. A few brief points through about the Actor model:

  • Actor model is message based
  • Actor models tend to do well with distributed systems (clusters). Sure event based systems can be distributed, but I think the actor model has distribution built in with regards to distributing computations. A new request can be routed to a new actor in a different silo, not sure how this would work in event based.
  • The Actor model supports failure in that, if hey cluster 1 apperas to be down, the observer can generally find a different silo to do the work

Also, check out drama. It is another nodejs actor model implementation.

stevebot
  • 23,275
  • 29
  • 119
  • 181
  • 1
    try set up a cluster with nodejs, you need docker, kubernetees and craft the distributed system. Also try to set up the usage of 1 more core in nodejs. Akka it is desinged to deal with those. also the maturity of nodejs itself, security, and the way to code that require another framework to do something, is a point that nodejs itself cannot be used for big distributed system, but just in a fashion of MSA at least. My opinion anyway. – Raffaello Sep 03 '18 at 08:58