Akka vs Swim: The Key Differences
by Fred Patton, on Feb 9, 2023 1:29:03 PM
The Swim platform simplifies the development and maintenance of real-time streaming applications. Akka gives developers the opportunity to easily create powerful, message-driven concurrent and distributed applications.
Users might use Swim to build a real-time streaming app that monitors cell service in real-time and automates remediation, whereas a developer might use Akka to build an order confirmation process for their food delivery app.
Despite their differences, Swim’s real-time streaming application platform and Akka’s widely-used vector-based language often are pitted against one another. Here’s where the confusion may come from, and why it’s so important to know why the two aren’t interchangeable.
Akka vs. Kafka
Before we dive deeper into the differences between Swim and Akka, it’s best to first highlight how Akka differs from Kafka, as the two are sometimes conflated as well.
Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala. Kafka, on the other hand, is a Distributed Log (immutable) rather than a Message Queue (mutable) like Akka. This means the consumer of a Distributed Log sees all messages, whereas the consumer of a Message Queue doesn't see the messages removed by other worker tasks.
Akka vs. Swim: The Three Key Differences
Developers often ask how Swim compares to Akka. At Swim, we narrow it down to three key differences:
- While both Swim and Akka have a runtime, only Swim has bindings for Java and Typescript for real-time UIs.
- Actors in Akka communicate via messages, whereas in Swim, state objects are universally addressable via web URIs and communicate via streaming APIs
- The two take different approaches to state management — we’ll expand more on this in a second, but, in general, Swim applications care about the syncing of distributed entity state and uniform access via streaming api, whereas Akka actors are more isolated and independent and use the sending of point-to-point messages.
The Limitations of Akka
While popular, Akka is not a perfect tool for every project. For starters, Akka actors are only accessible via the Actor Context. This makes it impossible for them to reach an actor from a client that wants to observe it (e.g. from another application or browser).
Additionally, Akka actors use messages to notify other actors about state changes. This is challenging because the sender has to know about and actively push messages to each of the recipients. Developers are left to determine how newly "interested" actors make it onto the list of recipients. The receiver may waste a lot of time processing useless messages when it wakes up, before it gets to a message that is really important.
A classic use case for Akka would be orchestrating a business function that requires distinct business functions that are better separated into individual services or components. Like Kafka, it can be used for pipelines, but unlike Kafka, these pipelines can be completely custom and more like a microservice than a processing node
How Swim Builds Upon Akka
Web Agents in Swim are similar to Akka actors in the sense that they provide a stateful, concurrent computational model with thread-safe access to state. But Swim focuses on the automatic linking of distributed state, setting the collective autonomy of stateful objects above individual autonomy, as with Akka actors.
In Swim, each Web Agent is universally addressable via a unique URI and any program (including a browser) can use this to access the state of the Web Agent. A Swim URI is a link to a streaming API "on the web." Swim via its universal streaming APIs, affords even external clients knowledge of the state held by stateful objects, which is very contrary to the private nature of Akka actor state.
Swim uses a distributed cache coherence protocol (WARP) that automatically propagates state changes of a Web Agent to all clients that have linked to it (via the streaming URI). The current state of any Web Agent is visible to any client that links to it, and state changes are automatically pushed to all clients.
These features help immensely when building applications. For example, real-time web UIs become simple to build since JS objects can continuously render the current state of a Web Agent because by simply linking to it, it will continuously stream state updates to the browser. It also makes application composition as trivial as object composition in an OOP system.
Implementing URI addressability, adding a protocol to propagate state changes and supporting multiple concurrent read access to an actor is pretty complicated to do with Akka.
Finally, Swim applications, while currently, Java based, rely only on the JVM (we use Graal) and the Swim platform, which is being rewritten in Rust. Many application DSLs are possible so you will eventually be able to use your favorite DSL and get all the power of Swim.
Getting Started with SwimOS
Swim applications care about the current state, not the sequence of changes that led to the current state. The primary focus of Swim applications is to stay in-sync with the real world, making your applications really real-time.
Our open-source implementation makes it easy for developers to get up and running with their real-time streaming applications. Check out SwimOS to get started on your own project.