Handling federation _entities queries without creating @Query

[RoMiRoSSaN]

See #2110

[t1]

The code looks good to me. I just don‘t quite get, what the resolvers are needed for. I’m happy to hear that you want to add documentation, Javadoc and tests.

[t1]

If I get this right, the resolversType is only used in the if block below, so we could move it there and simplify the trinary.

[RoMiRoSSaN]

Moved to federation builder block

[t1]

Suggested change

	if (schema != null && (schema.hasOperations()) || Config.get().isFederationEnabled()) {
	if (schema != null && schema .hasOperations() || Config.get().isFederationEnabled()) {

[RoMiRoSSaN]

I was wrong here (...). I fixed it

[t1]

I‘m not sure, if I got this right: graphql-java federation transformation is going to overwrite the _service query that we add here? It‘s just a dummy that is required to make the schema builder happy? Maybe it would make the code flow more understandable, if the method was named addDummyQuery. What do you think?

[RoMiRoSSaN]

yes, you right, i rename this

[RoMiRoSSaN]

I found this #1585, #521
Here how I understand was annotation FederationSource, but now smallrye graphql not contains it. The logic there intersects with my PR. For example, in NodeJS federation router itself sends requests about what and what fields it needs. And there it can be any object (list of parameters).
At the moment I have not yet come up with how creeate a universal wrapper object (method must have all required 'primitive' params. see test). With these changes, the router can obtain the required data. And most importantly, queries are not published to the schema. Exmaple, service extends external type other service

extend type Type key('id') {
  id: String external
  name: String external
  value: String requries('name')
}

If you request a field value will be sended request like

_entities(representations: { id: "id", name: "name", __typename: "Type" }) {
  __typename
  ... on ExtendedType {
    value
  }
}

value extended field. It turns out you need to make 2 requests, by id (default and may be query), and id and name (value requires field name).
And if you publish so many queries to the schema, it can become very large. And it may not be necessary for requests to be available exclusively to the federation router.
It can be useful only for federation

[RoMiRoSSaN]

It would probably be nice to have such an option.

record Vars(String id, String name){}
@Resolver
Product find(Vars vars){
   ...
}

and allow pass queries like

_entities(representations: { id: "id", name: "name", __typename: "Product " }) { __typename  ... on ExtendedType { id name value } }

_entities(representations: { id: "id", __typename: "Product " }) { __typename  ... on ExtendedType { id} }

in one method. or maybe it is wrong idea.

[RoMiRoSSaN]

Unfortunately, I couldn’t figure out how to make one general type. Too much magic

Needs simple changes in quarkus (add resolvers operations here)

[RoMiRoSSaN]

Hi @jmartisk, @t1. What do you think about it?
For example, This example in JS. And in Spring

[jmartisk]

Hi, sorry a bit busy, but I'll try to review at the beginning of next week...

[RoMiRoSSaN]

This will require changes that are present in #2184