Using swift with DAPR virtual actors?

masters3d · 2022-05-21T07:07:31.270Z

I just discovered the dapr project and I was curious what other folks think about this level of abstraction. Haven’t spent much time with the project yet but so far it seems to offer a way to write distributed actors in any language that interfaces with REST or gRPC. I am guessing that it should be possible to create a dapr swift sdk that exposes distributed actors in plain swift but be powered by dapr for setting up the transport and perhaps some long living state for actors that die.

Dapr Docs

Actors overview

Overview of the actors API building block

masters3d · 2022-05-22T22:20:59.012Z

Here is a little more information about creating a language specific sdk. In summary most of the API for a new language SDK is autogenerated but the Actor sdk part needs to be manual to take into account usability concerns for the target language.

github.com

dapr/dapr/blob/master/docs/decision_records/sdk/SDK-001-releases.md

# SDK-001: SDK Releases

## Status
Accepted

## Context
Dapr exposes APIs for building blocks which can be invoked over http/gRPC by the user code. Making raw http/gRPC calls from user code works but it doesn't provide a good strongly typed experience for developers.

## Decisions

* Dapr provides language specific SDKs for developers for C#, Java, Javascript, Python, Go, Rust, C++. There may be others in the future
  - For the current release, the SDKs are auto-generated from the Dapr proto specifications using gRPC tools.
  - In future releases, we will work on creating and releasing strongly typed SDKs for the languages, which are wrappers on top of the auto-generated gRPC SDKs (e.g. C# SDK shipped for state management APIs with the 0.1.0 release.) This is the preferred approach. Creating purely handcrafted SDKs is discouraged.
* For Actors, language specific SDKs are written as Actor specific handcrafted code is preferred since this greatly simplifies the user experience. e.g. The C# Actor SDK shipped with the 0.1.0 release.
  
## Consequences

Auto-generation of gRPC client side code from Dapr proto files allows Dapr to provide SDKs for the major languages with the 0.1.0 release and set us on the correct path to generate more user friendly SDKs by wrapping the auto-generated gRPC ones. There will be no auto-generated code for actor SDKs, which are also handcrafted to focus on API usability.

ktoso · 2022-05-23T01:13:06.092Z

Good question, let's see...

Let me preface this with a bunch of caveats: Dapr has been around for a while but I've never really dug deep into it. I think there's actually a lot of platforms we can either integrate with or make use of and make them have a "Swift native" distributed actor user experience. There's also Kalix ("Akka serverless") which is another runtime like this.

Can we do "virtual actors" with Swift's distributed actors?

Yes!

Our distributed actor design is very much so prepared to handle the virtual actor pattern; we "just" need the runtime impls to catch up a bit with the language

For example, you'll notice (quote from the docs you linked):

Each such actor is uniquely identified by an actor ID.

That's why distributed actors have the Self.ID which is managed by the actor system This is a common trait for all distributed actor runtimes, from Akka, Orleans and all the way to OTP and Dapr and others.

In general, you should probably start with:

Actors overview | Dapr Docs

as it explains the concept pretty well. And please note that the pattern originally comes from Orleans, so more docs for inspiration are available here:

Introduction | Microsoft Orleans Documentation

I'd also give Kalix a look, since Akka's "cluster sharding + persistence" is exactly the same as the virtual actors pattern in practice, and Kalix is the serverless offering.

https://docs.kalix.io/reference/supported-languages.html

I think it might be much easier to get a Swift SDK going for Kalix and we'd then be able to write both servers and clients using DA... (supported languages https://docs.kalix.io/reference/supported-languages.html )

Sidenote: Pure Swift

We could also implement a pure-swift solution for virtual actors based on the cluster library: GitHub - apple/swift-distributed-actors: Peer-to-peer cluster implementation for Swift Distributed Actors

I'm in the middle of updating it to the latest toolchains as we're preparing for WWDC, so within a few weeks one could start playing around with implementing Virtual Actors for the cluster. It'd mean you can "host" virtual actors with a very minimal deployment. Though of course the above mentioned managed runtimes are also interesting.

We could also look at extending the Swift AWS Lambda runtime:

GitHub - swift-server/swift-aws-lambda-runtime: Swift implementation of AWS Lambda Runtime

to be able to "host" virtual distributed actors...

So yeah, lots of work ahead of us and we'll need to figure out as a community which runtime is most interesting and try out a few as OSS libs I think

What about Dapr right now then?

I'll be honest here that it is unlikely that I myself will have the time to look into integrating with Dapr, but I do agree that such integrations is exactly what we should be doing with DA as it gets released with Swift 5.7

If you'd like to look into it I'm more than happy to offer consultations or something like that to help you write such Swift SDK for it

masters3d · 2022-05-23T14:53:58.863Z

I am thinking about spending time on this space since if this is successful maybe i can start using swift on the back end at work (a yak shaving exercise)

At first look I see three areas: Transport, Distributed Internal state, Reentrancy.

Do you see any other main areas between virtual actors and distributed actors in Swift?

For example:
swift distributed actors reentrancy is the default ( and only choice I think) vs most virtual actor frameworks making it configurable. So a client library that adapts swift DA to a virtual actor framework should default to DA design choices first.

github.com/dapr/dapr

[Proposal] Actor Reentrancy

opened 01:15AM - 09 Mar 21 UTC

closed 04:04PM - 01 Jun 21 UTC

halspang

kind/feature area/runtime/actor

## In what area(s)? /area runtime > /area operator > /area placement > /ar…ea docs > /area test-and-release ## Describe the proposal ### Background The [Virtual Actor Pattern](https://www.microsoft.com/en-us/research/project/orleans-virtual-actors/) provides a simple framework for developers to create distributed applications with many of the common headaches of distributed apps handled by the framework. In simple terms, Actors provide an abstraction that allows for easy concurrency/scaling, fault tolerance, and state management. A key attribute of Actors is that they are single threaded giving in-order execution. Information on Dapr's version of Actors can be seen [here](https://docs.dapr.io/developing-applications/building-blocks/actors/actors-overview/). ### Problem Currently, Dapr v1.0, does not allow for Actor Reentrancy. This, in conjunction with Actors being single threaded causes problems when Actors wish to communicate with other Actors. For example, say there are 3 Actors {A, B, C}. These Actor methods are reliant on each other, which leads to a call structure such like: Actor A -> Actor B -> Actor C -> Actor A In Dapr v1.0, this will cause a deadlock as the call from Actor C to Actor A will wait for the original call into Actor A to finish before allowing Actor C's call. Thus, Actors currently cannot be used for more complex workflows. The solution here is to add Actor Reentrancy to Dapr's framework. Actor Frameworks such as [Orleans](https://dotnet.github.io/orleans/) and [Service Fabric Reliable Actors](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-introduction) allow for Actor Reentrancy. ### Solution For this problem, we'll be following the path set by Orleans/Service Fabric fairly closely. In broad strokes, what we will do is: - Provide a config entry that specifies if an Actor is reentrant (opt-in) - Provide a call context (actor's present in chain) to the actor framework - If the actor being called is present in the call context, bypass the actor's lock #### Runtime The runtime will be responsible for handling the lock/reentry. It must be able to read the new config value (defaulting to false) and parse/understand the call context. We are choosing this to be an opt-in feature as dapr v1.0 does not support it so the customer must actively change their code in order to make use of this feature. This will stop unplanned changes in their functionality. #### SDKs/Raw Actors The SDKs and raw actors must be the ones to provide the reentrancy information to the dapr runtime. This includes building the call context and providing the new configuration value to the runtime. The call context should be a Set of Actors that are present in the call chain. Each time an Actor tries to call another Actor, the current Actors type and ID should be inserted into the Set. The config value can be specified with whatever language specific options are available (like annotations) or through a raw config which is served with the request to `/dapr/config`. @yaron2 @artursouza

ktoso · 2022-05-24T01:50:19.476Z

Reentrancy is not really something for you to work on here all that much. Rather, it is a function of how messages are delivered. As the runtime (SDK) implementation you can simply "wait to deliver the next message until the previous has been completed" and from the runtime's perspective you're not the cause of any reentrancy to the actor; if the (swift) actor happens to undergo reentrancy that's up to it and this is not something you're able to influence at all unless you are the Swift runtime -- so I suggest ignoring this topic at least for the first steps here.

What you have to actually implement I assume though is a minimal "SDK" that would bridge a declared distributed actor type into whatever Dapr expects types to call into.

This really isn't all that much different to what runtimes such as the cluster GitHub - apple/swift-distributed-actors: Peer-to-peer cluster implementation for Swift Distributed Actors need to do:

resolve actors for incoming IDs (keep some mapping in memory from ID to instances)
deliver messages to them (invoke executeDistributedTarget)
deliver replies to callers

The usual caveat applies though that I’m no Dapper expert, so that part would best to ask it’s devs

If you get started here feel free to let me know and we can look into what approach makes sense and I'm more than happy to provide hints and guidance! Looking forward to this!y