Apollo Federation Compatible Schema

[victormer]

Hello,

I am facing some problems integrating Ponder in Apollo Gateway. The reason is that the schema that Ponder generates automatically is not compatible with Apollo Federation Subgraph (I assume it should support introspection queries). There are some workarounds but it would be great for Ponder to support this integration. Thrown error:

E007: This endpoint doesn't support subgraph introspection via the Query._service field while resolving the schema for the 'ponder' subgraph
            Try running the command on a valid federated graph, or use the appropriate `rover graph` command instead of `rover subgraph`.

        See https://www.apollographql.com/docs/rover/commands/supergraphs#yaml-configuration-file for information on the config format.

Thanks

[0xOlias]

Hey @victormer, thanks for opening this. Would love to get this working.

For context, Ponder currently uses the rather barebones graphql-http NPM package, which doesn't have as many bells and whistles as Apollo Server, Pothos, GraphQL-Yoga, etc. Those libraries seem to support Apollo federation ~out of the box.

The challenge with enabling this automatically is that "subgraph" (in Apollo parlance) schemas include fields that are not meant to be made public. So, it would be unusual to include these in the Ponder schema by default because most users query it directly (are not using an Apollo federation).

So, it seems like our options are:

1. Add a graphql.enableApolloFederation config option that defaults to false, and a. Migrate to a more complete GraphQL server impl that adds these types/fields b. Update our schema generation manually to comply with the spec

What do you think?

[rplusq]

Love the option, would be a useful feature.

[o-az]

I assume it should support introspection queries

I tried introspecting the Ponder schema and it worked w/o any issues. You can try introspecting yourself @victormer:

curl --silent --location \
  --request POST \
  --url http://localhost:42069 \
  --header 'Content-Type: application/json' \
  --data '{"query":"query IntrospectionQuery { __schema { queryType { name } mutationType { name } subscriptionType { name } types { ...FullType } directives { name description locations args { ...InputValue } } } } fragment FullType on __Type { kind name description fields(includeDeprecated: true) { name description args { ...InputValue } type { ...TypeRef } isDeprecated deprecationReason } inputFields { ...InputValue } interfaces { ...TypeRef } enumValues(includeDeprecated: true) { name description isDeprecated deprecationReason } possibleTypes { ...TypeRef } } fragment InputValue on __InputValue { name description type { ...TypeRef } defaultValue } fragment TypeRef on __Type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } }","variable":{}}'

[victormer]

Hey @victormer, thanks for opening this. Would love to get this working.

For context, Ponder currently uses the rather barebones graphql-http NPM package, which doesn't have as many bells and whistles as Apollo Server, Pothos, GraphQL-Yoga, etc. Those libraries seem to support Apollo federation ~out of the box.

The challenge with enabling this automatically is that "subgraph" (in Apollo parlance) schemas include fields that are not meant to be made public. So, it would be unusual to include these in the Ponder schema by default because most users query it directly (are not using an Apollo federation).

So, it seems like our options are:

1. Add a graphql.enableApolloFederation config option that defaults to false, and a. Migrate to a more complete GraphQL server impl that adds these types/fields b. Update our schema generation manually to comply with the spec

What do you think?

I like your solutions. It would be great to be able to update the schema manually and also be as easy as allowing the user to change config to support Apollo Subgraphs as a feature.