Including unused directives in schema?

[terminalnode]

We have a schema that's about to be federated, but the second subgraph is not included yet. I generate the subgraph schemas using Apollo's rover subgraph introspect, and then create the supergraph using rover supergraph compose.

This has two issues for me, one directly related to graphql kotlin (I think) and one that might be more general graphql.

The issue I think is directly related to graphql-kotlin is that the subgraphs here don't include unused directives, if I just add my directive to a single property it's included in the subgraph but otherwise it's not. Can I force it to be included? Can I generate the subgraph some other way to make include it?

The issue that seems more general graphql, possibly, is that if I add a dummy property with the annotation (which is applicable to FIELD_DEFINITION and QUERY), the supergraph only shows it being applicable to QUERY and not FIELD_DEFINITION. In addition, it's removed from all field defs where it was in the subgraph. But there are built-in directives that have FIELD_DEFINITION as a location, so it doesn't seem to be illegal?

[dariuszkuc]

Hello 👋

The issue I think is directly related to graphql-kotlin is that the subgraphs here don't include unused directives, if I just add my directive to a single property it's included in the subgraph but otherwise it's not. Can I force it to be included? Can I generate the subgraph some other way to make include it?

Starting with the v7 graphql-kotlin-federation module now only includes federation directives that are actually used within the schema. Why do you need to include all federation directives?

The issue that seems more general graphql, possibly, is that if I add a dummy property with the annotation (which is applicable to FIELD_DEFINITION and QUERY), the supergraph only shows it being applicable to QUERY and not FIELD_DEFINITION. In addition, it's removed from all field defs where it was in the subgraph. But there are built-in directives that have FIELD_DEFINITION as a location, so it doesn't seem to be illegal?

This sounds like a question more about Apollo Federation behavior than this lib. As you know directives fall into two categories -> executable directives (user specifies them in a query) and schema directives (defined on schema elements). AFAIK supergraph composition will automatically preserve executable directives (as long as their definitions match across all subgraphs that define them) BUT you need to explicitly opt-in to preserve schema directives through @composeDirective (as they are meaningless to the router). Also by any chance did you want to use directive on FIELD (executable) location vs FIELD_DEFINITION (schema)?

[terminalnode]

My thinking is that our frontend will be basing their client on the federated schema, so even if our directives are executed in the subgraph regardless it's useful that they're visible in the supergraph too.

It does sound like maybe I want FIELD instead of FIELD_DEFINITION, but graphql-kotlin is not really happy with my using of FIELD. One of our directives is checking if a user has a role that's allowed to read certain data, and otherwise replace it with null, so our response entities look something like this:

data class ResponseEntityGraphql(
  val id: Int,
  val name: String,
  @RequireRole(CanReadSecretData) secretData: String?,
) {
  @RequireRole(CanReadSecretData)
  fun parsedSecretData(): SecretData = SecretData.from(secretData)
}

giving us errors like these:

Caused by: com.expediagroup.graphql.generator.exceptions.InvalidDirectiveLocationException: Directive requireRole was specified in unsupported FIELD_DEFINITION location (val xyz.ResponseEntityGraphql.secretData: kotlin.String?). This directive can only be applied on one of the supported locations: FIELD, MUTATION, QUERY.

The first error I can get around by using @get:RequireRole(...), but the latter gives the same error and I can't seem to find any sites that fix it. How can I make the annotation apply to the field and not the field definition?

The annotation in question is a KotlinSchemaDirectiveWiring which overrides onField. This method seems to be meant for overriding GraphQLFieldDefinitions (which I assume are FIELD_DEFINITIONs and not FIELDs), but there's nothing else to work with fields I think?

[dariuszkuc]

My thinking is that our frontend will be basing their client on the federated schema, so even if our directives are executed in the subgraph regardless it's useful that they're visible in the supergraph too.

AFAIK we (Apollo) don't preserve those custom schema directives in the API schemas (i.e. schemas that clients interact with). You can preserve them in the supergraph schema through @composeDirective but I believe they will be stripped out from API schema.

It does sound like maybe I want FIELD instead of FIELD_DEFINITION, but graphql-kotlin is not really happy with my using of FIELD. One of our directives is checking if a user has a role that's allowed to read certain data, and otherwise replace it with null, so our response entities look something like this

FIELD is executable location, i.e. something that clients specify in their queries - think about @include/@skip etc. It sounds like you do want to add it on actual fields in the schema so that should be FIELD_DEFINITION location.

[dariuszkuc]

BTW if you are using router then auth is a built in functionality that could simplify your setup (as those policies would be enforced at the router level) -> https://www.apollographql.com/docs/federation/federated-types/federated-directives#controlling-access