Federated service doesn't always need a Query type

[erikhh]

I'm using graphql-java in combination with Apollo federation-jvm (0.5.0). The new schema validation in 16.1 seems to break one of my services.
When it starts I get the errror: "Query" must define one or more fields.

Under 15.0 the exact same schema definition works fine.

This service only adds additional fields to existing types. It has nothing useful to add to the top level Query object. I would prefer not to add some artificial dummy field to the Query type just to please the graphql-java validation.

Is there a chance the validation might be loosened a little at this point? Or can I manually disable/ignore/skip it somewhere?

[andimarek]

I am sorry to hear that it doesn't work, but this projects goal is to support the official GraphQL spec.

We don't have the capacity to maintain derivations from the spec, therefore we don't support non spec features in general.

I hope you can understand.

Best,
Andi

[tinnou]

This issue is closely related to the effort of updating apollo federation jvm to the latest graphql-java version (16.1).

While this would go beyond the scope of just supporting the GraphQL spec, it does make lives easier when using graphql-java with Apollo Federation.

As suggested, we could expose a way to merely skip certain validation rules and/or replace with a different set of rules, this feature would be provided "at your own risk".

[bbakerman]

Since we are talking about hacking around the standard, you can do this.

You can define a field x : int to make the validation happen.

Then you can use graphql.schema.visibility.GraphqlFieldVisibility to remove the field dynamically at runtime

[andimarek]

I am reopening it to clarify some details:

As outlined above this projects goal is not to support non standard spec, but maybe there is an alternative to make this useable without breaking spec:

@erikhh @tinnou Can you help me understand better why apollo federation needs an empty Query type? Thanks

[erikhh]

I am sorry, my issue could have been described in better detail. And I was also maybe a bit beside the actual point. My sincere apologies.

In my project the schema file does not specify a Query type. But after the schema has been parsed the federation-jvm library dynamicaly adds a Query type like this one:

type Query {
  _service: _Service
  _entities(representations: [_Any!]!): [_Entity]!
}

Which makes the end result spec compliant but the validation takes place during the parsing of the schema file now, and this makes it fail before federation-jvm can work it's magic.

I have solved this by adding this bit to the schema file.

type Query {
  _service: _Service
}

type _Service {
  sdl: String!
}

This makes the schema parser happy and federation-jvm is going to add it anyway. It's probably even a good thing to make the schema file more complete.

Thanks for your time and input everyone!