Skip to content
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

How to setup configuration of application #153

Open
yosiyuki opened this issue Jun 25, 2013 · 8 comments
Open

How to setup configuration of application #153

yosiyuki opened this issue Jun 25, 2013 · 8 comments

Comments

@yosiyuki
Copy link

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

@kgriffs
Copy link
Member

kgriffs commented Apr 26, 2016

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.

@kgriffs kgriffs closed this as completed Apr 26, 2016
@kgriffs kgriffs reopened this Apr 26, 2016
@kgriffs kgriffs added this to the On Deck (Non-Breaking Changes) milestone Apr 26, 2016
@jasonab
Copy link

jasonab commented Oct 28, 2016

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

@kgriffs kgriffs added proposal and removed question labels Oct 28, 2016
@nZac
Copy link

nZac commented May 5, 2019

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

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

@KennethLim314
Copy link

KennethLim314 commented Mar 5, 2020

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
Copy link

dambros commented Apr 16, 2020

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
Copy link
Member

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
Copy link

dambros commented Apr 16, 2020

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

@vytas7
Copy link
Member

vytas7 commented Apr 16, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants