@include and @skip directives lead to irrelevant errors about graphene HOT 2 CLOSED

The @include and @skip behavior in Graphene closely follows what is defined in the GraphQL Specification. Firstly, after parsing the query string, the entire parsed AST is validated during the validation phase. Evaluation of the directives happens after the validation, during execution. Therefore we cannot change the behavior to your request, as this would break the rules of the spec. The purpose of validation is to ensure the type integrity of each query. Therefore, it does not make any sense to query fields that may or may not exist on your query, or to design your schema that way.

GraphQL is a strongly-typed language, and the schema serves as a contract between the client and server. In order for the server to fulfill that contract, it needs to know exactly what fields are queryable and what types they return. If a field is not queryable, it should not be included in the schema to begin with, and the server should not return it as an available field. Therefore, from a design perspective, it makes sense for the server to return an error if a non-queryable field is included in a query, regardless of whether it is excluded using the @include directive.

There's several ways to elegantly solve your issue using the tools GraphQL provides, under the premise that you can modify both APIs:

1. Mark your banana box field as nullable
   This way, you could have it on each query without the resolver failing in case it is not present. Since you already know when it is null on the client-side, you wouldn't even need to add any additional checks.

2. Use an Interface or Union
   You could model your Store as an interface with two Implementations:

interface CommonBanana {
  id: ID!
  common fields
}

type Banana {
  id: ID!
  common fields
}

type BoxableBanana {
  id: ID!
  common fields
  bananaBox: BananaBox
}
Type Query {
  banana: [CommonBanana]
}

And then query it like this:

query bananas {
	banana {
		id
        commonFields
        ... on BoxableBanana {
			banana_box {
				id
				size
			}
        }
	}
}

In any case, I'd strongly recommend exploring solutions such as Apollo Federation (implemented in graphene-federation) to stitch together the two APIs and prevent issues like this from arising. It's important to note that having two almost identical but separate GraphQL APIs is not an issue that can be solved in Graphene, but rather it's a matter of design decisions in your architecture that may need to be reconsidered. If that's not possible, the only way to avoid defining the query for each case is to modify the query AST on each request in your specific GraphQL client. Other than that, using fragments makes your life easier as well in this case 🙂

I hope my suggestions could provide some help, please feel free let me know if you have further questions.

Cheers

from graphene.

Thank you for the quick reply! And thanks a bunch for the clear recommendations. I think this helps me on my way sufficiently. I will definitely look into Apollo Federation, I hadn't heard about that yet.
Regarding our design decisions: I agree that the situation I described is quite specific and it may not be exactly what Graphene is designed to solve, but there is no other straightforward way for us to tackle our use case without introducing a lot of redundancy in our codebase.
Thanks a lot once more!

from graphene.