After the announcement of distributed actors, I was excited and began to dive deeper into the topic. Unfortunately, couldn't find any examples that covered it comprehensively. However, this hasn't stopped me from learning. I started reading books about Akka and Erlang and created a small repository where porting Akka in action examples, but quickly realised that there were still some missing pieces.
So, to fill those gaps, I've created a small example with several goals:
To reduce the learning curve for new developers.
To cover, at least partially, some concepts like event sourcing.
While it's based on Swift distributed actors, the project also incorporates:
As a learning project, it could also serve as a helpful example for other developers.
Currently, the app is in an early stage, though basic functionalities are working:
You can spin several nodes and form a cluster, such as:
main, which orchestrates other actors and connections.
room, to spawn room actors.
database, for persistency and event sourcing. You can even play around and split it into two separate nodes.
Basic fault tolerance, in case of room and database unavailability (time out, crash)âthe main node can continue working and spawn all needed actors on its own.
A basic iOS/macOS app client with chat, user/room creation, and room search.
Would be nice to hear some feedback. Want to be this example as actor modelcorrect as possible, and as I'm only learning and don't have much of experience in writing concurrent and distributed apps using actor modelâwould be nice to hear some thoughts from people who have this experience.
Also would like to mention next steps I want to cover:
Debugging is hard. Like really hard sometimes, even on a single node (cluster can just crash ). Wanna add swift distributed tracing
@Honza_Dvorsky pointed out that it would be nice to add swift openapi generator, which is a good point. Will try!
Maybe adding some simple authentication an spin application somewhere on my raspberry pi4 or VPS and have some more insights
Yes, event-sourcing would be a nice standalone package! There's various approaches but the overall idea should be quite abstractible, especially with macros and the flexibility you get from actorReady so you can store it and register it for "when events arrive we'll call you"
I'm personally a huge fan of doing something like LiveView, that'd be really cool
Seen some interest in the community before, and maybe interesting for someone, decided to pack some stuff into Virtual Actor pattern, so here is some basic and naive implementation:
Idea is that you can have transparent actors in the system referenced by some custom id, e.g.
let actor = try await factory.get(id: "first_example", dependency: SomeDependency())
Improved a bit error and crash handling (Let it crashâ˘ď¸) to self recover the service if something happens.
Removed some stuff, like new swift foundation, for simplicity. And overall some parts of code look way better now.
First of all, already posted in different topic, but now we can do simple event sourcing. You can think about event sourcing as autosaves in gamesâwhatever bad happens you can jump to last saved state. The way it works is you just add plugin to the system, conform desired actors to EventSourced protocol and update the logic to handle events.
Removed websockets. This is an interesting point, basically while moving to openapi @Honza_Dvorsky suggested that you can also remove ws and use streams. And this was suprising for me, as I've always thought that things like SSE works one way. But apparently you can do bidirectional streaming by initialising streams both way. Sounds obvious now, but And as I think it's not quite discoverableâended up creating a PR with an example. Thx again @Honza_Dvorsky and @beaumont for input and help.
After all the updates really like the state of the code nowâquite simple, but you have fully working chat example with db, event sourcing, recovery and crash handling. Will try to improve it further, some still missing (like postgresql journal for event sourcing), but overall think next steps would be finally to play with infrastructure, like real device (raspberry) or VPS. This will include deploying, node discoverability and etc.
Hope there will be a nice demo soon, with documentation and tutorial.
Can you expand more on your thoughts of building something like LiveView? I was just playing around with LiveView and was thinking something like that but built in swift would be amazing.
Technically it should be doable: have an actor with state on server side, update state and only send diffs to client to render with SwiftUI. Converting state to SwiftUI views would be hardest part though, there is LiveView native initiative, and if you checkâit takes a lot of effort to port it SwiftUI and Compose.
Yea, super cool idea. I think even if you did something like just handled the state on the server (similar to this GitHub - hansihe/live_data) and all the UI was still just controlled on client based on the state being updated on the server would be good.
Sort of like a redux pattern but going client<>server.
So, to fill those gaps, I've created a small example with several goals:
). Wanna add 
Looking forward for next steps.
)
