Swift-chat: Showcase for distributed application

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.
15 Likes

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

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

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

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

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.

1 Like

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

Yeah, would be good. :blush:

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

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