-
-
Notifications
You must be signed in to change notification settings - Fork 537
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
Add support for extensions to the HTTP protocol #3461
base: main
Are you sure you want to change the base?
Conversation
Hi, thanks for contributing to Strawberry 🍓! We noticed that this PR is missing a So as soon as this PR is merged, a release will be made 🚀. Here's an example of Release type: patch
Description of the changes, ideally with some examples, if adding a new feature. Release type can be one of patch, minor or major. We use semver, so make sure to pick the appropriate type. If in doubt feel free to ask :) Here's the tweet text:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @omarzouk - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟡 General issues: 1 issue found
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Docstrings: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3461 +/- ##
==========================================
- Coverage 96.22% 96.21% -0.01%
==========================================
Files 526 527 +1
Lines 33999 34037 +38
Branches 5610 5621 +11
==========================================
+ Hits 32714 32750 +36
Misses 1048 1048
- Partials 237 239 +2 |
CodSpeed Performance ReportMerging #3461 will not alter performanceComparing Summary
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! Can you add a test to ensure the exension dict is actually correctly passed down the chain? 🙂
Additionally, we can investigate merging the http protocol extensions with subscription extensions (need to double check if we support this already in strawberry). It might also make sense to add the protocol extensions to Info
@erikwrede Hi! yea I think I need to do a fresh take on this, I think I hit a dead end with my current approach, I've been investigating how to do it, and I think we have a couple options: 1- Wrap the context field in another object that holds the extensions and the context, i.e. wrap the field before this line, then unwrap it inside the Info class. We would then introduce an 2- Extend the definition of the get_context function, add a 3rd parameter called The benefit of doing Option 1 would be that we can add this right away to http, without having to modify other protocols, and just include a type check for the wrapper in the What do u think? should I go ahead and do Option 1? |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
hi @erikwrede, I went ahead and implemented Option 1 mentioned above, which is to wrap the context object and unwrap it in the Info getter. I also added a new test that is passing successfully. Please let me know what you think. 🙏 |
Reviewer's Guide by SourceryThis pull request adds support for the 'extensions' field in the HTTP protocol for GraphQL requests. The changes involve parsing the 'extensions' field from the request, propagating it through the File-Level Changes
Tips
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @omarzouk - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟡 General issues: 3 issues found
- 🟢 Security: all looks good
- 🟡 Testing: 1 issue found
- 🟡 Complexity: 2 issues found
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.
pinging @patrick91 as well, since we discussed this originally in #3224 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments, but I'm not totally aware of this, so other @strawberry-graphql/core will be able to do a better review :)
@dataclass | ||
class ContextWrapper: | ||
context: Optional[Any] | ||
extensions: Optional[Dict[str, Any]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same suggestion as above
extensions: Optional[Dict[str, Any]] | |
extensions: Optional[Dict[str, Any]] = None |
Co-authored-by: Thiago Bellini Ribeiro <[email protected]>
Co-authored-by: Thiago Bellini Ribeiro <[email protected]>
Co-authored-by: Thiago Bellini Ribeiro <[email protected]>
for more information, see https://pre-commit.ci
Hello! apart from the extra check for list in the parameter parsing which is potentially redundant and might be removed, as I understand it, that change is also not really blocking for this PR, right? #3558 could be updated to remove the list parsing for Is there any other comments regarding this PR? the approach in general around wrapping context and exposing the extra field in the |
Hi! I have merged main to include #3558 and removed the extra list type check for the extensions param. Anything else you guys would like me to change about this PR? if not I can should I create a release file? |
strawberry/types/info.py
Outdated
@property | ||
def input_extensions(self) -> Dict[str, Any]: | ||
if isinstance(self._raw_info.context, ContextWrapper): | ||
return self._raw_info.context.extensions | ||
return {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how come this is called input_extensions? 😊
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
honestly, I just didn't have a better name 😅 I just felt extensions
is used in so many contexts in strawberry and people might be confused as to which one this is. But I'm happy to change it to whatever you think makes most sense
context_wrapper = ContextWrapper( | ||
context=context, extensions=request_data.extensions | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this context wrapper only to pass request data?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes exactly. Since the context
data comes from get_context
and that can be any type of object the user decides to return, this felt like a safe way to attach more data
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try to review and merge this this week 😊 thanks for the patience!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you so much! 🙏
hello! sorry to keep pinging, we are really eager to use this in our APIs, do u think its possible to get some traction on it? I'm happy to help any way I can @patrick91 🙏 |
@omarzouk sure, I think I'll have time this week(end) (I'm currently travelling) 😊 And please consider sponsoring us, so we can prioritise issues better ;) |
@omarzouk an update on this, I think I found a nice way to pass the request extensions to info, but it is quite different from this, so I might try it in another PR |
Description
The GQL spec specifies a field called extensions as part of the request parameters spec in the HTTP protocol. We are missing support for this
Adding the field to be parsed and propagating it as part of the
Info
object. This is done by wrapping the entire context object in a temporary container, and then unwrapping it inside theInfo
context getter. A new function is also added to theInfo
class calledinput_extensions
. It exposes the extensions data.Example usage by the end-user:
Types of Changes
Issues Fixed or Closed by This PR
extensions
Request Parameter for the HTTP protocol #3224Checklist
Summary by Sourcery
This pull request introduces support for the 'extensions' field in HTTP requests, allowing it to be parsed and included in the ExecutionContext. This change is accompanied by updates to the documentation and new tests to ensure proper functionality.