Hide queries in schema

[robp94]

Is there an option to hide certain queries and not publish them in the schema? For federation, we need many queries who should not be called directly. Would be nice if we could hide/exclude them from the schema.

@jmartisk @t1 @phillip-kruger

[phillip-kruger]

No, if it's not in the schema, it also will not be executable (at lease not from graphql).

[phillip-kruger]

You can ignore certain fields on object, to not be exposed on the graphql side, see https://download.eclipse.org/microprofile/microprofile-graphql-1.0/microprofile-graphql.html#ignorable_fields

[t1]

IIUC, it's only just two extra queries, isn't it?

[robp94]

Yes, we are not talking about the same thing, what I mean is if you want to extend Type A with a type B in Service B:

type A {
  bs: [B!]! @requires(fields : "id")
  id: ID! @external
}

type B {
  id: ID!
  idOfA: ID!
}

We need a query like this:

  addBToA(idsOfA: [String]!): [A]

And then let's say you do this for multiple services and types and A is an interface and has multiple subtypes, so you get quite a lot of queries which should never be called directly (that's why I would like to hide them) only the Federation resolver needs them.

[t1]

Maybe you can rename your addBToA to something more on the business level... and your problem might disappear!

Say A is Product and B is Price. Then you can use the same query in Price as you use in Product (I use a non-batch example here for simplicity):

@Query public Product product(@Id String id)

Then there is only a single query. Or am I wrong?

If you do need to also be able to get a Price with the priceId (and not only via the Product and its id), you'll have a second query, of course. But that's what you then want, isn't it?

[robp94]

If you do need to also be able to get a Price with the priceId (and not only via the Product and its id), you'll have a second query, of course. But that's what you then want, isn't it?

Well, I want to be able to resolve it, but without a query in the schema :), if possible.

If you remember your old implementation, this would look something like this in code:

public Price resolveFederationPrice(@FederatedSource Product product)

So we did not get a new Query. While now, we need something like this:

public Product resolveFederationPrice(String id)

My problem with this is it looks kind of like resolving the product entity, but this is not what the query is really doing.

In the old implementation, there were two types of resolvers, the main entity resolver and the federation entity resolver.

[t1]

But this resolveFederationPrice method does resolve a Product! It's just not the full Product but only the "view" that the Price service has about the product: a product with an id and a price. If you give it the same name that the Product (or any other) service uses, e.g. product or productById, you'll have only a single query in the schema!

[robp94]

Interesting, thanks for the hint.

[robp94]

Thanks again, works as it should.