-
Notifications
You must be signed in to change notification settings - Fork 327
[WIP] Proof of proof of concept for Tide-global state #100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* Use Extesions from http crate to store tide-global(ish) state such as config.
If two |
@tirr-c no it isn't. I didn't realize that possibility. I think one way to handle this is to wrap it in a struct with a id of some sort and instantiate one for every app instance. |
I've been trying to somehow add a On the other hand Basically what I'm looking to return from functions such as The idea is to go from this in the insert case: to something along the lines of: STATE.entry::<Config>().insert(config); And for the read side to something along the lines of: {
let config = STATE.entry::<Config>().get();
// Do something with `config` here
} // `config` gets dropped here and the lock is unlocked. So the one way I can think of doing this is that instead of wrapping the |
@bIgBV so I agree that the key missing thing right now is a way to communicate data with middleware and endpoints during the "static" phase (that is, for configuration). And I also agree that we'll ultimately want this configuration to be easily loadable from the external environment. That said, there are a few reasons that I'd prefer to achieve these goals more along the lines of #5:
However, the key thing to making that work will be getting some variant of typemap working for configuration. I left a comment with some ideas here, lemme know what you think! |
Description
Proof of concept for global state internal to Tide.
Motivation and Context
Currently we have the following form of state in Tide:
(Quoting @tirr-c ):
But this does not provide a way to save state internal to Tide, but accessible globally within the framework itself, as an example design for #5.
This means that things which need to be accessible internally to Tide such as say a
Config
struct and a root logger are no longer accessible.This PR provides a proof of concept by using a typemap wrapped in a reader-writer lock to provide synchronized access to this global state.
How Has This Been Tested?
I modified the logging middleware and added a dummy
Config
struct to demonstrate particular usecases for such a system. Right now if an example is run, we log a message mentioning what environment the server is running in and what address is it bound to.The biggest issue I have with this design is:
Having to access the
STATE
variable directly.I think a better design would be to wrap the
STATE
typemap with our own struct and provide apub get
method and apub(crate insert
method. This way we provide a way for the users of the framework to only read the application configuration, while internally within the framework we have read-write access.This would mean that we can provide route level configuration as mentioned in #5 as well.
I tried to implement this in this design, but couldn't make it work with the current design.
Types of changes
Checklist: