Add strawberry.context

[jkimbo]

Description

This PR introduces strawberry.context which gives you access to the current context through the magic of Context Variables. I propose that becomes the recommend way to access the context rather than through info. What do you think @strawberry-graphql/core ?

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[codecov]

Codecov Report

Merging #1243 (254854a) into main (5dbbb04) will decrease coverage by 0.57%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1243      +/-   ##
==========================================
- Coverage   97.63%   97.05%   -0.58%     
==========================================
  Files          88       89       +1     
  Lines        3382     3366      -16     
  Branches      496      495       -1     
==========================================
- Hits         3302     3267      -35     
- Misses         44       62      +18     
- Partials       36       37       +1     

[patrick91]

do you think we can:

1. type it somehow?
2. use context.user_loader instead of context["user_loader"]

?

[jkimbo]

1. type it somehow?

I'm not sure how we could type it unfortunately. You can always cast it when you import it but that's not great. I think that's one of the downsides of this proposal.

2. use context.user_loader instead of context["user_loader"]

That should already work. See tests.

[patrick91]

yeah, I wonder if doing:

ctx: Context[Something] = strawberry.context

is annoying or not.

Do we get benefits by using ContextVars and still using parameters (and dependency injection)?

[jkimbo]

Do we get benefits by using ContextVars and still using parameters (and dependency injection)?

You can start defining (and exporting from Strawberry) stand alone functions that get useful things from the context. E.g. current_user() The only issue with that is there wouldn't be a way for those functions to be known about early in the execution to register things into the context before resolution happens. E.g. you couldn't do get_dataloader(UserDataloader) inside a resolver without also registering an extension on the schema that would inject the dataloader into the context. Dependency injection would allow you to that.

[jkimbo]

Oh it would make the data validation proposal (#820 (comment)) a bit cleaner. Instead of having to pass info to the .validate() function you could grab the context from the context variable.

[AndrewIngram]

Pros:

1. Most common reason for needing the info arg is gone, so more more consistency in resolvers in general
2. Doesn't feel like a mismatch given context is typically fairly static per query (mutations might update it, but regular queries shouldn't), whilst the rest of info differs per query+resolver.

Cons:

1. Less explicit
2. There's nothing stopping code further down the call stack from using strawberry.context either, which could result in some nasty coupling.

The second con is the one that most concerns me. I've seen Flask codebases where its magic request object is accessed at every conceivable point in the call stack and it's an absolute nightmare of tangled layers. As such, we'd want to discourage people from accessing strawberry.context outside of the "GraphQL" concern. Arguably the deepest it should go is Dataloaders (if that). There'd definitely need to be some "here be dragons" warnings needed in the docs.

But the fact that this guidance would make its utility mostly about simpler resolver signatures, it makes me wonder if there's enough of an upside to this? Perhaps there is though.

[jkimbo]

@AndrewIngram I'm beginning to wonder if there is much benefit to this as well. Especially because you can't type it effectively and the first Pro you list could be solved by #374

[jkimbo]

As discussed in our recent community meeting, I'm going to close this PR since we don't think it provides enough value to be worth the potential confusion.