dimamik
Vault - a lightweight process-scoped global data storage with immutability guarantees
Vault is a lightweight Elixir library for immutable data storage within a process subtree.
Due to Elixir’s actor model nature, it’s common for a process to have global context that is valid for every function call inside the process and its children.
For example, this context can include:
- A user when processing a request
- A tenant in a multi-tenant application
- Rate limiting buckets/quotas
- Cache namespaces
- API or client versions
- And many more, depending on your application domain
Vault.init/1 provides you a guarantee that the context can only be defined once per existing process subtree, so you won’t override it by accident. This makes it easy to reason about your context origination.
# Initialize vault in parent process
Vault.init(current_user: %{id: 1, first_name: "Alice", role: "admin"})
# Access data from any descendant process, even these not linked!
spawn(fn ->
Vault.get(:current_user) # => %{id: 1, first_name: "Alice", role: "admin"}
Vault.init(current_user: :user) # => raises, because the ancestor already has vault initialized
end)
# Access data from the parent process itself
Vault.get(:current_user) # => %{id: 1, first_name: "Alice", role: "admin"}
In my case, repeatedly passing the user from the connection and GraphQL context into lower-level functions became hard to maintain.
A typical flow involved extracting the user from the Absinthe resolution context, performing substantial business logic, and only at the end persisting data or writing to the audit log - both of which also required the user. Maintaining this plumbing was cumbersome.
Because the user is immutable for the lifetime of the request and retrieved only once, storing it in the process dictionary is an elegant way to eliminate redundant parameters and simplify the overall flow.
This approach does introduce an implicit dependency - the need to understand where the value originates - but since it’s initialized exactly once, the trade-off is acceptable. In most cases, callers can simply read the value without needing to think about its source.
Properties
- Immutability guarantees. Initializes only once per process tree - will raise if one of ancestors already has vault initialized.
- Familiar API - API is the same as for Elixir’s
Mapmodule, except forVault.initpart. - Any child process will have access to the parent’s
Vault. We’re usingProcessTreelibrary by JB Steadman, which does all the heavy lifting of traversing process trees and propagating data back. You can read more about how ancestors are fetched in this amazing blog post by the library’s author. - Once the vault is found on one of the parents, it’s cached (set in the child’s process dict), so next fetches are faster.
- We have a set of
unsafe_*functions to perform updates on already initialized vault. These updates won’t propagate to the children that already initialized the vault.
https://github.com/dimamik/vault
I’m really curious what you guys think!
Most Liked
LostKobrakai
I’m not sure using links is a great idea here. Links connect processes in all manner of configurations. There’s no clear parent/child hierarchy there. For that you’d rather want $ancestors or $callers (Task — Elixir v1.20.2). Then you’re also no longer traversing a graph, but just a list of parents.
dimamik
I’ve just released Vault v0.2.1.
Thanks to @Asd, @jswanner, and other folks suggestions, we’re now relying on ProcessTree library to traverse process tree in an efficient and inclusive way. It relies on Process.info(pid, :parent) and fallbacks to processes $ancestors and $callers if OTP<=24 or if parent process is dead, which is exactly what we need in this case. Big kudos to JB Steadman, the author of ProcessTree.
Since ProcessTree does all the heavy lifting for process traversal now, I was going back and forth on the need to have Vault as an abstraction layer above it in the first place. And I think it still has value in guaranteeing the immutability for the process subtree and defining a clean API on how to initialize and access this data.
My primary use-case was for propagating across a single process, so I definitely still see some value being added, but I would love to hear what you guys think!
garrison
Contexts have a very particular use-case in a React-style engine, namely they allow components to re-render based on dependencies through a memoization barrier, effectively turning the dependency tree into a DAG. You can get pretty far with a tree but the DAG models certain types of dependencies better (theme styling is a common example).
LiveView doesn’t have memoization (though maybe you can do something similar with LiveComponents?), but even if it did the engine has to actually understand the dependency DAG for things to update. If you just write your assigns into the process dictionary you can access them in distant children, but they won’t be able to re-render when things change which breaks the entire declarative model.
Surface actually tried to hack Contexts onto LV and eventually gave up for this reason.
Popular in Announcing
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








