I have followed FBP, but from a distance out of interest. Fiddled with NoFlo UI a couple of times (didn’t find it really intuitive, tbh). The idea is fascinating. Question is, if it is the most fitting model for future fediverse… and in this distributed, task-oriented environment.
At FBP on wikipedia, you see mention of the Actor Model and this model will be taken to next-level by @cwebber Spritely project:
Mandy component: “[…] Thankfully this should be a very clean mapping, because both Goblins and ActivityPub follow the classic actor model. Mandy’s design is to bridge the worlds of distributed Goblins programs and ActivityPub by providing an easy mapping between them.”
We have concurrent, distributed processes / workflows / orchestration, and it would be interesting to see how they can be modeled. And especially while still being easy to reason about, design, implement, test, control, etc. at scale.
There’s not really a lot of information out there.
As I said elsewhere, I am really interested in domain-driven design (where ‘bounded contexts’ match linked data vocabulary designs), because of the ways it allows non-technical people be directly involved in the translation of their needs to technical solutions, as well as well as advantages in terms of modularity and testability later on.
I know DDD and actor model go well together. Also there’s a recent talk by Vaugn Vernon about Reactive DDD that comes close in terms of concepts. Traditionally Microsoft with .NET solutions are exploring the DDD fields, and in the past I’ve briefly worked with a (then just released) Akka actor model, where you can also find distributed workflow processes solutions.
The image above shows something close to a microservices architecture, except the green services are much larger than is common in these designs. They represent a single domain’s bounded context.
In part 3 of this distributed systems article series Actor Model Hidden in Plain Sight a lot comes together with DDD, CQRS, Actors. And workflows, where they exclaim “It’s a finite state machine!”:
Lastly there are other cool projects that might take a lot of the work away from app implementers. A notable example is:
From their docs:
Temporal Workflows are suitable to implement scalable actor systems. A Workflow execution represents a single actor, uses signals for events, and automatically keeps track of the state using the backend service.
A typical pattern is to have a Workflow instance per business entity:
- A Workflow that tracks the status of a single IoT device.
- A loyalty program that accumulates reward points per customer.
- A routine that manages a unique resource in a conflict-free manner.
Each flow responds to asynchronous events from a target entity, persists some corresponding state, and takes actions according to the defined rules.
