Building Modular Akka Systems

Question

We are building a multiple-component Akka-cluster-based system. Every component is a separate Play! project and on start it joins the Akka Cluster and components start looking-up actors to work.

Problem

I have two problems with this setup:

1. Writing test code is very hard (we didn't figure out this yet), specially when writing tests that rely on multiple actors coming from different components. How can we solve dependency and create a proper cluster in the test-code (between two play applications!)

2. During development, every developer has to start multiple Sbt instances to boot the system (different play projects) and this eats the entire system memory and development becomes incredible slow.

What I'm Looking For

I was thinking of using the cluster "roles" property to do selective boot-up, this means that there is only a single Play project and components are (modules) and on-boot of the play project I will scan the current "roles" property of this instance and based on that I start or stop certain components/actors.

This will make testing easier but I don't know exactly how to do this in Play, specially that some components actually offer RESTful API (Play Controllers) and I don't know how to enable/disable routes and controllers on boot-time of play.

Is there any document or something that shows the right way to build a modular distributed system or any clues? (something also that relates to how SBT should be setup?

Edit 1: The project lives in a single repository and has a single sbt build (multiple-projects)

Answer 1

This is a good question, and I’ll answer it in parts, although I am not a Play expert.

1 – Writing Tests

I would recommend testing modules in isolation to avoid the exponential explosion of necessary test cases. To this end actors are a very nice abstraction because you can trivially mock any actor by injecting a TestProbe instead of the real ActorRef. In a cluster you will typically want to look up services on other nodes, which means that in a test you construct your probe and inject its path (probe.ref.path) instead of the path you would look up in the production system.

The second aspect concerns integration tests for which you want multiple services to participate. In this case you don’t need to start a “proper” cluster involving multiple JVMs, you can just spin up multiple ActorSystems within your test and have them communicate on "localhost".

2 – Development Deployments

It is not necessary to run multiple instances of sbt, you can just create a suitable Main class which starts all required ActorSystems within the same process, just like for the tests as mentioned above.

3 – Node Role Management

The ActorSystem managed by Play will typically have a “frontend” role. In addition to that one you can start more systems with different roles, which are not Play applications by themselves. Triggering different behavior—starting different services and initiating different activities—makes sense based on the node’s role, we do that ourselves in tests and real applications.

On the question of disabling certain routes for certain roles I do not know enough to answer.