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?
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.
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?
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.