Sharing state in an Umbrella application

Questions / Help
1

So I’m working with a large umbrella application that has an http interface and a lot of umbrella dependencies that call micro services, databases and perform all sorts of tasks.

These all need access to a lot of basic data in varying amounts. We’re currently doing it by being explicit, i.e. in the web app, we get the data from the conn and pass it to the umbrella apps. This is starting to get pretty tricky, especially since we have to write ever more boiler plate code to make sure we’re passing the right stuff.

I’m trying to come up with an alternate to this: since each request comes in with a request id, you could have a request bucket application that associates an agent to that request id so all you need to do is pass around the request id. It’ll probably come with a request bucket plug called once at the top of the plug chain to start the agent and again at the bottom of the chain (or using the before send macro) to stop the agent. These will all be supervised in the usual way and have a registry component. (Alternatively, we could do this with ets, or a more mature cache application, especially since we’ll want concurrent reads, ttl and serialized writes, etc…)

I’m wondering if anyone else had any experiences with this kind of thing and whether I’m heading in the right direction?

2

It depends on the kind of problem you want to solve.

If you have the feeling that you need to write too much boilerplate to make sure that you’re passing the right stuff, it might be worthwhile to extract the things you want to request from the conn object in its own behaviour, which makes the contract between requester and requestee explicit.

Adding an extra process to store state only makes sense if you want to keep this state for a longer time, while other stuff is going on in the meantime. For conn objects this does not make a lot of sense because you usually want to return some response back to the user as soon as possible. When working with a persistent connection such as Phoenix Channels, it might make more sense to use an approach like this.