Support the `extensions` Request Parameter for the HTTP protocol

[omarzouk]

trafficstars

Hello! The GQL spec specifies a field called extensions as part of the request parameters spec in the HTTP protocol. We have recently come into a usecase where we would like to make use of this field to provide extra metadata to our apis in a federated graph world.

The extensions field is supported in the subscriptions protocol, however it is not supported in the HTTP protocol.

Up until now we had been using HTTP headers to achieve the passing of metadata, however, in order to reuse the same API on subscriptions, we now have to put the metadata in the extensions field. This means our clients would need to send the data in the header when using HTTP and in the extensions field when using subscriptions. Our APIs also have to be able to handle both. It would be nice to be able to use the extensions field everywhere.

Feature Request Type

• [X] Alteration (enhancement/optimization) of existing feature(s)

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[patrick91]

@omarzouk do you have an example on how you'd use this? it will be useful for me for writing the tests 😊

[omarzouk]

it is a map object similar to the variables field, so the input request would look something like this: {"query":"query getAccount($id: ID!) {\n getAccount(id: $id) {\n id\n name\n\n }\n","variables":{ "id": "XXX" }, "extensions":{"some_property": "some_value"}}

We would then like to have access to it in the get_context function somehow. Perhaps under the Request object?

[patrick91]

thanks!

this might be a good time to refactor some parts of accessing the context. Ref #1258 #2687

How urgent is this?

[omarzouk]

Would be nice to have it in the upcoming couple months. We would love if we can start using it early next year

[omarzouk]

@patrick91 hello! do u think there is bandwidth to prioritise the refactor you mentioned during January? if not, could we add support for the variable to the existing setup?

We would love to start using extensions soon. As opposed to headers, extensions are meant to work on both HTTP and Websockets which make them much better at carrying soft metadata, like device timezone or locale

[patrick91]

@omarzouk I think we can make it happen, just to clarify, you want to be able to update value of extensions from a resolver, something like:

@strawberry.type
class Mutation:
    @strawberry.mutation
    def login(self, info: Info) -> bool:
        token = do_login()
        info.context["extensions"]["something"] = 123
        return True

[omarzouk]

We don't need to edit it, we just want to be able to read it. Today its not part of the Request object we get in the get_context function

[patrick91]

@omarzouk oh, gotcha, thanks 😊