@euri10
I read about that but I didn't think it was totally right and I didn't know how to adapt it to other resources while retaining the nice properties of the aforementioned approach.
Like for instance, if I were to create a Kafka producer for every single session that would be really inefficient, and it looks like the docs create a local sqlalchemy session at each request and then closes it.
So specifically, my issue with dependencies like suggested in the tutorial is that I didn't see a way to create an app-level instance of dependencies - where I want to avoid recreating the same instances over and over again on every request, and I also want to avoid having ephemereal resources that are initialized by a function call without really associating it with the app context.

The docs say:

request.state is a property of each Starlette Request object, it is there to store arbitrary objects attached to the request itself, like the database session in this case.

Where I would instead want anapp object where I can store arbitrary objects that can be accessed throughout the application, like you can choose to store objects in theapp object in Flask and then refer to those objects using thecurrent_app context.

If I can find out a nice way to do this using this or figure out a way to adapt dependencies such that they are immediately accessible from a common location.
I'm not sure if I like the thought-model that has you call a function to initialize something somewhere. I prefer initializing everything in a factory and then associate the created instances with the app itself as to make that globally available as needed by simply usingapp.state.db orapp.state.kafka_producer orapp.state.elasticsearch.

@euri10
I think I figured out how to approximately do something like this. Therequest object provides access to theapp object. If you assign variables to theapp objects you can later access it. See for instance this line in an example API that I quickly made.

https://github.com/Atheuz/Test-API/blob/master/api/routers/basic.py#L11

Hmm, in your case, why not a global object that you can import and use directly everywhere?

As you are not using something that requires transactions or something similar, just more or less atomic operations (Kafka, Redis), you can use the same object everywhere. You don't have to attach it to the app, just import it and use it.

Dependencies are for cases that need to somehow read data from the current request or similar things.

Adding things to the request state is for situations where you need to have something through all the request, like a SQLAlchemy session.

But in your case, if it's something that can be at the same application level, you don't really need to put it as a property in the application, you can just have the global object/variable in a file (module) and import it anywhere you need it. If you import it from different Python files, Python will take care of re-using the same object that was imported before.

Would that work for you?

@tiangolo

I've tried to keep global objects that I can import and use anywhere in other projects, but I've just found the experience of instantiating objects and attaching them as properties on the app context to be simpler to reason about and less confusing.

I think, my problem with the other approach, is a feeling that I don't know "when"/"if" global objects are instantiated, with the app context I handle instantiation through a factory where objects that I want to use are clearly instantiated and attached to the app context. If the app throws up an exception like:AttributeError: 'app' object has no attribute 'kafka_producer' - I know where to look for the problem, in the factory.py file where that instance SHOULD have been created but for some reason was not.
This also makes it simpler to test: Create an app in the conftest.py file, and then every functional object that the app requires is available through the app context without having to import 9 different functional objects. Also makes it simple to mock these properties out in cases I'm not interested in their behaviour, but rather if they get called as intended.

Examples of this in use:
Creating a logger for every single file in the application feels messy, whereas with this approach you would instantiate a logger once in the factory and assign it to the app as a property. Then the logger would be available through the app, like this:app.logger.info("I am a log entry", extra={"meaning-of-life": 42}).
This is what Flask does as well, where there is a logger object assigned to the app context that can be used anywhere in the application throughcurrent_app orapp.

Similarly with config, I like to have that be part of the application itself, so I can always refer to it anywhere through the app without having to think about if I should import it. For instance, if I define an hostname for an API that needs to be used multiple places in the application, I would like it to be available through the app context without having to import anything, like so:app.config["FIREBASE_API_URL"].
This is also what Flask does, also reachable throughapp orcurrent_app.

See here for an example of instantiation of a logger object:
https://github.com/Atheuz/Test-API/blob/master/api/factory.py

Then it's reused here, using therequest.app that's available:
https://github.com/Atheuz/Test-API/blob/master/api/routers/basic.py#L11

This almost works for me, except not everything in an API is necessarily an endpoint, for instance you can have actions or background tasks that you call from endpoints to perform some work, and in that case therequest instance is not available unless you pass it directly through from the callee. In Flask they resolve this by having it be possible to importcurrent_app, as a proxy forapp.

This is a pattern I've been using a lot over the last year and I don't know if I would want to change it without a good reason to.

I extended the pattern in my example API a little bit:

https://github.com/Atheuz/Test-API/blob/master/api/actions/storage.py#L14

Seems to be alright like this.
I'll also look into putting the objects into modules and then importing them at some point.

Cool! I'm glad you found a way to solve your problem that matches well your workflow.

@tiangolo still not totally sure about this approach. I'd like a standard way to do it. In Flask, apparently the current_app object is magic and handles locking per session that's using it so you don't end up in bad situations. The above mentioned approach would work in instances where the object to be used is atomic and/or thread safe. So I think for Kafka and Redis it might be OK. I doubt that it's OK with SQLAlchemy and I need to do something like the dependency injection to establish a local session.

For SQLAlchemy you probably want to attach the session to the request (that's what SQLAlchemy recommends), as in the docs:https://fastapi.tiangolo.com/tutorial/sql-databases/

@tiangolo, I'm working with a colleague on a FastAPI application and we're having a discussion about the merits of global module variables vs. passed dependencies. I've been advocating dependency passing as a way to modularize an application, govern access, facilitate testing, etc. For example, I've been advocating that a database repository object should be passed as a dependency of some kind and should not be a globally accessible module variable.

We noticed this issue and your comment about globals on 2019/3/17. I'm hoping you'll weigh in again since we're looking to the broader Python community for guidance on this question. Are global module variables considered idiomatic Python? Are the pitfalls of globals less applicable here? Can you think of FastAPI reference applications that heavily use module globals as a way to distribute dependencies like caches, database repositories, etc?

@ebarlas you're 100% right. The way FastAPI documentation proposing app configuration assuming you have global variables for use with (angular-style inspired)? dependency injection, and in big projects it will be a huge mess, but MORE important - it's complex to write reusable modules for different apps.
Other frameworks trying to solve this in different way, happily FastAPI is based on starlette - and there isrequest.state and request.app.state variables.Pseudo-code for proper application configuration will look something like this, use this factory in tests to override settings without ugly hacks like documentation suggests.

create_app(**config):  config.set_default('debug', true)  config.set_default('db_url', 'sqlite://:memory:')  app = FastAPI(app)  app.state.config = config  setup_database(app)  # reads app.state.config, register middleware for request.state.db_session  setup_redis(app)  # something similar  return app

I am experiencing troubles with this, what do you think of my implementation

@MchlUh you are commenting on a closed issue and I do not see 1) what your problem is and 2) how the snipped relates to global state. I suggest you create a new question issue and provide a minimal working example.

I am experiencing troubles with this, what do you think of my implementation

@MchlUh you are commenting on a closed issue and I do not see 1) what your problem is and 2) how the snipped relates to global state. I suggest you create a new question issue and provide a minimal working example.

Thanks, I'll follow your advice

I would not use the app or request state as that can't be properly typed, so tooling like editors and mypy won't be able to help you make sure that you're not making bugs detectable by those tools, giving you certainty that your app is bug free, at least from type errors. You would also not get autocompletion in your editor.

If I needed to have something that works like a global but that I would be able to change, for example in tests, I would use a function that returns the value, and I would put anlru_cache to make sure it returns the same thing always. Like in the docs for settings:https://fastapi.tiangolo.com/advanced/settings/#creating-the-settings-only-once-with-lru_cache

Sorry for the long delay! 🙈 I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.

Just wanted to follow up here and explain a situation where using Globals is not the right approach vs using app level state@tiangolo.

If you wanted a long running aiohttp session, you might just create it globally. However there is a weirdness in aiohttp that does not allow you to use the timeout parameter if youdont create the session inside of an async task. And so what would be the option here? Seems like the only way to do that is to create the session on app start and attach it to the app state no? The use case here is you don't want to open a new session for every app-request, as a single session per app is preferred in some scenarios.

I've had a good read through the thread and this is also something my company are debating internally at the moment. The main themes seem to be:

1. Typing and IntelliSense Support
2. Clarity and Control Over Resource Instantiation
3. Simplicity and Ease of Use
4. Consistency and Singleton Assurance

I would like to suggest a resource manager.

# resources.pyimportloggingfromsqlalchemy.engine.baseimportEnginefromsqlalchemyimportcreate_engineclassResourceManager:def__init__(self):self._logger=Noneself._db_engine=Noneself.get_logger()self.get_db_engine()defget_logger(self)->logging.Logger:ifnotself._logger:self._logger=logging.getLogger("my_logger")# Configure the loggerreturnself._loggerdefget_db_engine(self)->Engine:ifnotself._db_engine:# Setup database engineself._db_engine=create_engine("sqlite:///mydatabase.db")returnself._db_engine# Create a global instance of ResourceManagerresource_manager=ResourceManager()

# some_other_module.pyfromresourcesimportresource_managerdb_engine=resource_manager.get_db_engine()logger=resource_manager.get_logger()

Advantages are:

• Easy and clear to understand how global resources are instantiated
• Specifying method return types provides your IDE with the information it needs to provide auto-completion
• Can be imported from any module easily
• Confidence that only one instance of a resource has been instantiated
• Resources are created before the app begins serving requests

This solution is very similar to the onetiangolo suggested for get_settings() where he uses lru_cache but perhaps this version provides the clarity that people seem to be wanting?