Read configuration only once, and pass that as State to request handlers

federico commented

2025-10-03 22:41:13 +02:00

Collaborator

Currently a lot of configuration is read as-needed from disk; look for code that calls env::var. I think it would be better to do this:

Read configuration only once at the beginning of the program. Tell the user in a friendly way if some configuration is missing (environment variable, or a file, or an unparseable file, etc.).
Pass that config data as State to request handlers.

A little brainstorming:

Our configuration, and in general any shared state, can be represented as Arc<Something> so it can be shared across threads.
I don't know yet how much of the config data is immutable (hostname? port?) versus the mutable part that the user can configure at runtime via the web app. In the past I've found it beneficial to separate immutable parts from mutable ones - the latter require a Mutex to make them read-write while shared via an Arc.
If we can synthesize configurations during tests, instead of always reading them from disk... well, this makes tests easier.

Currently a lot of configuration is read as-needed from disk; look for code that calls `env::var`. I think it would be better to do this: * Read configuration only once at the beginning of the program. Tell the user in a friendly way if some configuration is missing (environment variable, or a file, or an unparseable file, etc.). * Pass that config data as [`State`](https://docs.rs/axum/0.8.6/axum/extract/struct.State.html) to request handlers. A little brainstorming: * Our configuration, and in general any shared state, can be represented as `Arc<Something>` so it can be shared across threads. * I don't know yet how much of the config data is immutable (hostname? port?) versus the mutable part that the user can configure at runtime via the web app. In the past I've found it beneficial to separate immutable parts from mutable ones - the latter require a `Mutex` to make them read-write while shared via an `Arc`. * If we can synthesize configurations during tests, instead of always reading them from disk... well, this makes tests easier.

ro commented

2025-10-03 23:24:35 +02:00

Collaborator

Hm. I'd say the port number and the directory listings are probably the only things I want to keep in the env, and that's negotiable depending on what file type we decided on to hold the other settings.

I'm down to just get rid of the json files completely and consolidate it into something else.

As long as whatever we land on is easy to read, I'm down for whatever.

And hard agree with changing when those settings are read to just one time instead of multiple requests. I need to read up more on shared state so I have a feel on how to implement.

Hm. I'd say the port number and the directory listings are probably the only things I want to keep in the env, and that's negotiable depending on what file type we decided on to hold the other settings. I'm down to just get rid of the json files completely and consolidate it into something else. As long as whatever we land on is easy to read, I'm down for whatever. And hard agree with changing when those settings are read to just one time instead of multiple requests. I need to read up more on shared state so I have a feel on how to implement.