Graphene: Parameterized mutation sent with an Apollo Client

Created on 27 Dec 2017  路  11Comments  路  Source: graphql-python/graphene

Is there any support for Apollo Client ? It doesn't seem to handle properly variables sent from an Apollo mutation on the client.

capture d ecran 2017-12-27 a 01 16 55

capture d ecran 2017-12-27 a 01 16 39

    def mutate(self, info, name):
        category = Category(name=name)
        return CreateCategory(category=category)
馃憖 more info needed

Most helpful comment

@jkimbo I'm having what may be the same issue, but the linked repo is now unavailable. @jkimbo can you recall what you suggested in your PR?

All 11 comments

@dbrrt is this still an issue for you?

@jkimbo Yes, I temporarily switched to a nodejs back-end

That's a shame. Can you give any more details so I could reproduce the error?

https://github.com/dbrrt/apollo-aiohttp-graphene

You can start client using yarn and yarn start
and server with make

I'm calling mutation with Apollo in : https://github.com/dbrrt/apollo-aiohttp-graphene/blob/master/client/components/views/Home/mut.js

It works using GraphiQL, so the problem might be related to Apollo client directly.

@dbrrt I found the issue and fixed it in https://github.com/dbrrt/apollo-aiohttp-graphene/pull/1

Basically the schema execute function needed the variable values that were being sent by Apollo.

@jkimbo I'm having what may be the same issue, but the linked repo is now unavailable. @jkimbo can you recall what you suggested in your PR?

@freyley I think I'm having the same issue with React-Apollo and Graphene 2.1.8:

query {
    formFieldsByNoteType(noteType: DAILY_NOTE) {
        mnemonic
    }
}

That works just fine and returns this response:

{
    "data": {
        "formFieldsByNoteType": [
            {
                "mnemonic": ...

But this query:

query FormFieldsByNoteType($noteTypeParam: NoteType!) {
    formFieldsByNoteType(noteType: $noteTypeParam) {
      mnemonic
    }
  }

with the variables {"noteTypeParam": "DAILY_NOTE"} provided using Postman returns this response:

{
    "data": null,
    "errors": [
        {
            "message": "Variable \"$noteTypeParam\" of required type \"NoteType!\" was not provided.",
            "locations": [
                {
                    "line": 1,
                    "column": 28
                }
            ]
        }
    ]
}

@jkimbo I think my Graphene implementation probably makes the same error that you fixed in that PR to @dbrrt's repo, which is now private. Can you clarify how you fixed this?

Also @dbrrt would you be able to post the changes @jkimbo included in the PR to your repo you made private? It would be a huge help.

@jldillman Absolutely. Here's the schema

# schema.py

import random
import asyncio
import graphene

class CreatePerson(graphene.Mutation):
    class Arguments:
        name = graphene.String()

    ok = graphene.Boolean()
    person = graphene.Field(lambda: Person)

    def mutate(self, info, name):
        person = Person(name=name)
        ok = True
        return CreatePerson(person=person, ok=ok)


class Person(graphene.ObjectType):
    name = graphene.String()
    age = graphene.Int()

class MyMutations(graphene.ObjectType):
    create_person = CreatePerson.Field()

# We must define a query for our schema
class Query(graphene.ObjectType):
    person = graphene.Field(Person)

schema = graphene.Schema(query=Query, mutation=MyMutations)

If I remember correctly, I omitted to pass the data in graphql_post method, here was a working version

# in main.py
async def graphql_post(request):
    payload = await request.json()
    response = await schema.execute(
        payload.get('query', ''),
        variable_values=payload.get('variables', None),
        return_promise=True
    )
    data = {}
    if response.errors:
        data['errors'] = [format_error(e) for e in response.errors]
    if response.data:
        data['data'] = response.data
    jsondata = json.dumps(data,)
    return web.Response(text=jsondata, headers={'Content-Type': 'application/json'})

@dbrrt Thank you so much! Your last snippet was _exactly_ what I needed to see. Turns out our naive implementation of a request handler was only passing the query part of the request, and leaving the variable_values parameter empty. My afternoon of troubleshooting was now worth it. Thanks again!

Was this page helpful?
0 / 5 - 0 ratings