minhajuddin
Is it a good idea to store context in Process dictionary/Registry for HTTP requests?
Passing arguments around is sometimes a pain while working with Elixir. However, for Web apps, since each request runs in its own process, we should be able to stick bits of context into the Process storage. For instance, we could stick the user_id, api_key, role and things which are may be needed across the app.
So, you would do this at the beginning of the request (maybe in a plug)
Process.put(:api_key, conn.assigns[:api_key])
And in other modules where we need an api key just do Process.get :api_key , This may also be a good place to store tenant info in multi tenant apps.
I feel this goes against the purity of functional programming, but seems like it could have practical use cases. One gotcha would be to make sure that we pass the arguments when things cross a process boundary, but that should be ok.
Would love to hear what you guys think about this
Most Liked
gregvaughn
The first rule of BEAM Club is that we do not talk about the Process dictionary
gregvaughn
Whoa. Now we’ve come full circle. I also briefly reference this thread in that talk! ![]()
michalmuskala
Two places where popular elixir libraries use pdict are:
- logger - to store the metadata that is attached to each message. It would be hard to achieve current API without use of process dictionary here - you’d need to pass logger state around to each logger call.
- ecto - to keep track of current transaction. Inside the function passed to
Repo.transactiona database connection is checked out and saved in process dictionary. Subsequent calls to otherRepofunctions look for the connection in the process dictionary before checking out another connection. It would be possible to rule out the use of pdict here with explicit connection passing. Because of ecto’s architecture connection cannot be shared between processes (to have a transaction spanning multiple processes) - because of this the use of pdict is not particularly limiting, but it does introduce a level of indirection and makes some use cases problematic (those that require dynamic connection management).








