Federation graph calls sequential vs parallel

[sm-the-explorer]

Hello Everyone,

I have a graph model like below and if I have federated sub graphs one resolving names and other for profile and both the subgraphs need the input value(customerId) to be accessed. Can you please help me understand the below questions

1. How to pass the customerId to subgraphs ?
2. will the sub graphs resolve the data in parallel or sequential ?

type Query {
customer(customerId: String!): Customer!
}

type Customer {
names: Names
profile : Profile
}

type Names {
firstName: String,
lastName: String,
middleName: String,
fullName: String,
prefix: String
}

type Profile {
email: String,
phone: String
}

TIA

[srinivasankavitha]

This will be handled by the gateway. I assume you are using Apollo's gateway implementation for federating your graph?
The query to the gateway has the customerId. The gateway will then handle passing that using an _entities query to each of the services owning the subgraph so they can resolve and return data. As for whether it is sequential or parallel, the gateway optimizes the query plan such that it can parallelize the sub queries as much as possible, unless there is a dependency requiring it to be sequential.
The docs on federation by Apollo give a good overview of how it all works together:
https://www.apollographql.com/docs/federation/

Hope this helps.

[sm-the-explorer]

@srinivasankavitha Thank you for the response.

[sm-the-explorer]

@srinivasankavitha yes I am using Apollo graph and I have some follow-up questions. Can you please help with these questions as well ?

1. The model in the example I mentioned above would not work as is for federation, I need to add @key for some field in customer domain and @external in the subdomains names and profile. But there is no field in Customer domain that is being resolved in any subgraph. So my question is, do we have an option to resolve the subdomains profile and names just based on the input params without using @key and @external ?

[srinivasankavitha]

For the original example, you will need to use @key and @external in order for federation to work. If you are not adding those, the gateway will not be able to populate the customer id to request names and profile from the respective subgraphs.

you can have a standalone query to just one service that takes a customer id as input and the gateway would just send that to the profile or names service, i.e. only one of them. If you need a single query to be resolved by multiple services, you will require federation.

[sm-the-explorer]

2. Just to make the above model work I have added a dummy id in Customer domain and marked it with @key annotation and set the the customerId I get in input parameter to this dummy id to make the federation work. And I have the implementation in such a way that Customer domain with the names subdomain are being resolved in one subgraph and the profile is being resolved in another subgraph, with this approach the problem I am seeing is until the names is resolved in one subgraph, profile is not being resolved in another subgraph. which is adding latency to overall query response. so is there a way I can resolve names and profile in parallel ?

example logic of resolving my names and Customer in the initial subgraph:-

   @DgsQuery
    suspend fun customer(@InputArgument cid: String): DataFetcherResult<Customer> {
        return DataFetcherResult.newResult<Customer>().data(Customer(id = cid, names = null))
            .localContext(cid).build()
    }

    @DgsData(parentType = DgsConstants.CUSTOMER.TYPE_NAME)
    suspend fun names(dfe: DgsDataFetchingEnvironment): Names {
        return cnSvc.getNames(dfe.getLocalContext())
    }

[srinivasankavitha]

The gateway should ideally handle parallelizing the resolution as long as the service that handles the profile also has the customer id. I assume there is CustomerService that owns the Customer type and provides the appropriate id? If not, which service owns the Customer type as part of the subgraph?

[sm-the-explorer]

@srinivasankavitha yes, there is a customer service which is handling Customer type as well as Names, and Profile type is served by a different service.

In the the 2nd use case I mentioned, when I use @DgsEntityFetcher for resolving Cusomer type in customer service, I am able to resolve names and profiles in parallel.

Thank you.