Falcon: How to setup configuration of application

[yosiyuki]

I'm wondering how I can set environmental configurations in falcon framework.
Does someone tell me how to do it.

[kgriffs]

Sorry for missing this question... just came across it while trying to get the Falcon issue tracker organized!

In case the info is useful to anyone, I'll just mention that Falcon isn't opinionated about how you configure your app; you are free to use ConfigParser, or directly load a JSON/YAML/TOML file. You can have a module that exposes a (get_config()) call and memoizes on first use to consolidate config handling in one place without relying on global logic / variables.

[jasonab]

Has there been consideration of having a config dictionary on the application, a la Flask? I will admit it comes in handy there.

[nZac]

@jasonab there is nothing to say you can't put a config attribute on the application.

api = falcon.API()
api.config = load_config()

[KennethLim314]

Isn't there? The api object has no __dict__ attribute and you can't assign additional attributes to it due to the use of __slots__.

[dambros]

It seems this doubt has been around for a while and I think @KennethLim314 is correctthat we can't add to the App class because of the __slots__. What is the current consensus on how to best approach this problem? Use a "utils-like" module and have it serve the dict everywhere?

[jmvrbanac]

Historically, I've often just inherited from API and put it on there since as I needed to build other things (such as signal handling) around the API anyhow.

class MyCustomAPI(falcon.API):
    def __init__(self, cfg):
        self.cfg = cfg
        # --- snip ---

Likewise when creating resource classes or middleware, I often pass in the cfg and usually something to handle db session management.

If you would prefer it to be on a request, you can add it to your request from a middleware using the context capabilities: https://falcon.readthedocs.io/en/stable/api/request_and_response.html#falcon.Request.context
I'm not a big fan of putting full configs in there though as it's a lot of data to float on every request. I generally use the context area for role, authentication, or request specific custom data.

[dambros]

@jmvrbanac Thanks for the explanation. The idea behind it fits my needs :)

[vytas7]

Adding to what @jmvrbanac said, in some simplistic scenarios you may get away with just passing the configuration object down to resources and middleware, i.e., as showcased by above, but without even storing it on the API / App instance. Our upcoming ASGI tutorial could serve as an example. This way, it's usually very straightforward to inject configuration in testing.

As also covered in our FAQ, another popular way is making configuration available via a module that can be imported anywhere. Just make sure it's not loaded and cached upon import, but only when needed. I've gone this way at work, it does the job too. The main advantage is simplicity (accessible everywhere). Although using global stuff is usually not the best practice, but it's a lesser sin for things that _are_ global, like configuration and logging.