Is DA Right for Web Apps?

So I have a web app that currently loads all the data into memory and just runs using Vapor. So far so good. I prefer not to use databases. I would like to split the app to a data portion (backend) and website (front-end). Eventually, I would like to be able to run multiple front-end servers and back-end servers to handle the load as my growth continues.

Is this something I would do using distributed actors? Or should I be looking somewhere else?

Thanks!

Hi there,
It may depend on the exact guarantees you want from this system, but if your goal is to just have all state in memory and and even avoid persistence, distributed actors are one way to do this.

You can basically think of them as a in-process cache of data along with logic (the actor's implementation) that encapsulates this data (the actor's state).

You can definitely some api entrypoints written in e.g. vapor, and then immediately send off distributed actors for business logic handling. This way you'd always get the "current state of given entity" by means of always reaching the same actor.

You should keep in mind though that computers and networks can fail, so what would happen if a node hosting your specific entity goes down; and you say you don't want to use any kind of persistence? It's hard to suggest specifics without knowing the exact business scenario you're addressing here.

I'm kind of expecting you'd want Fresh take on Virtual Actors - allowing "get user for some user defined id" ยท Issue #1057 ยท apple/swift-distributed-actors ยท GitHub a form of the virtual actor pattern provided or implement it yourself; please feel free to chime in on that ticket if that seems to be something that'd help you use DA cluster in your use case -- feedback helps us prioritize work.

1 Like

Yes, I think you are 100% on point. From what I read, Virtual Actors is where I want to be. Put a vote in for me on that one.

Hah right, noted -- thanks.

Would you mind explaining your use case a bit more? Would you be using the cluster only to spread computation basically, or also use it a bit like a cache?

Sure glad to,

Ideally I would like to be able to create a front-end user facing app and a back-end data provider. I would like for both to spin up as many nodes needed to handle whatever workload and I would like not to be able to think about it at all.

I do have persistence in my app. Ideally my backend would load all the data to memory, and when a new node comes up, it automatically pushes the most recent state to the new node. All changes in the data (on any backend node) would synchronize across all nodes and also to storage persistence.

I might need multiple front end nodes and only one back end on one day or vice versa on another day. The point is I'd like to not think about it at all. Let the cluster just do what the cluster does, but with a Swift framework.

Hope that helps!

1 Like