1

Work in Progress

swift-chat is a simple distributed application created to explore and showcase distributed actors.

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.

:top: So, to fill those gaps, I've created a small example with several goals:

  1. To reduce the learning curve for new developers.
  2. 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:

  1. 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.
  2. 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.
  3. A basic iOS/macOS app client with chat, user/room creation, and room search.
21 Likes
2

Would be nice to hear some feedback. Want to be this example as actor model correct 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 :man_shrugging:). 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 :slight_smile:
  • Add some basic node discovery.
3 Likes
3

Also, where I have 0 experience is event sourcing and consistent persistency across multiple nodes.
So far checking this articles:

Would be nice if someone can provide more knowledge, at least links to the articles they know/liked.

1 Like
4

This is a really awesome effort and I’ll try to make time soon to dive in! Thanks a lot for driving this! :star_struck:

3 Likes
5

Yeah, thx! It's fun! :upside_down_face: Looking forward for next steps.

6

Think event sourcing is a good candidate to be extracted into separate package sometime in (distant) future.

Another idea I have in mind—would be interesting to discover and try to create Phoenix LiveView-like framework out of websocket connection example.

2 Likes
7

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" :slight_smile:

I'm personally a huge fan of doing something like LiveView, that'd be really cool :slight_smile:

1 Like
8

Yeah, would be good. :blush:

(don't be excited much though, my current state of event sourcing is simple event logging :sweat_smile:)

9

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())

Would be nice to work and improve it further. :slightly_smiling_face:

1 Like
10

Just wanted to share a bit on progress of my small distributed actors showcase demo:

  • 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. :sparkles:
  • Added Swift openapi generator.
  • 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 :man_shrugging: 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. :slightly_smiling_face:

6 Likes
11

This is how I am finding out about Swift distributed actors. This is super cool!

1 Like
12

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.

1 Like
13

Thx, glad it makes someone curios! :slightly_smiling_face:

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.

1 Like
14

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.

1 Like
15

This looks awesome I need to give it a try!

2 Likes
16

Thx! Constantly improving it, so looking forward for any feedback! :slightly_smiling_face:

1 Like