Data flows in CAF provide a high-level API for building processing pipelines in a data-oriented way. They complement the message-based actor communication and allow expressing complex data processing pipelines in a declarative way. Data flows can span multiple actors and may even connect actors to other, non-actor components. For example, actors can process frames from a WebSocket connection.

In this guide, we learn how the flow API is structured and how to build processing pipelines using flow operators.

As Carl Hewitt puts it, one actor is no actor. They come in systems where some actors are focused on handling incoming tasks while others focus on orchestration and supervision.

Some actors only exist to manage other actors. They detect failing workers in the distributed system via monitoring or linking. After detecting failing subordinates, they may spin up replacements or at least make sure their subsystem fails collectively to avoid partial errors. In the latter case, an even higher level actor may then jump to action.

All actors in CAF live in an actor system, which provides a runtime environment for actors that implements message dispatching, error propagation, cooperative scheduling and networking. Connecting two or more actor systems results in a single, interconnected distributed actor system.

In this guide, we learn how the networking layer of CAF enables distributed applications and how CAF represents remote actors locally.

Last time, we learned about internal vs. external views to actors, objects lifetimes and explicit state management.

In this part, we extend our discussion on actor handles by introducing messaging interfaces for static type checking. Afterwards, we revisit the stateful actors API to implement extensible state classes for statically typed actors.

CAF attaches many labels to actors: event-based, blocking, statically typed, dynamically typed, and so on. When delving into the depths of the API, users may get lost in technical details and subtleties without grasping the big picture first.

In this guide, we first take a high-level look at the basic ideas and concepts behind the API before we dissect the class hierarchies and outline how the pieces fit together in the big picture.

Barely any application runs without a user-provided configuration. At the very least, a distributed system needs to allow users to tell how to reach remote nodes in the network or how other nodes in the network may reach this node.

CAF makes it easy to configure various aspects of applications and also allows users to fine-tune CAF components.