How to access additional data across federated services
See original GitHub issueFederation is great! I love it! This demo is also awesome, thanks! I do have one question about obtaining data from external services.
Let’s say I work on the Accounts team. We’re using Apollo Federation and have teams working on independent federated services. All of our teams are totally independent, we cannot request features from other teams. If we want to implement something, we have to do it on our own.
Our customers want a running total of the products that they have purchased. We have saved a list of upc
codes locally for each purchase that a user has made. A user account record has the following data in our database:
{
"name": "Jonathan Toews",
"productsPurchased": [1, 2, 3, 2, 1]
}
So we are going to add a field that will resolve to the total dollars that a users has spent on all of the products:
type User @key(fields: "id") {
id: ID!
name: String
username: String
totalDollarsSpent: Float
}
However, when I get to the resolver I do not have enough information about the products that the user has purchased. I only have their UPC codes:
totalDollarsSpent: (user) =>
user.productsPurchased
.map(upc => /*Here I also need the price, but I don't have it*/)
.reduce((total,product) => total + product.price, 0);
- What would be the best solution for completing this resolver?
- Is this a use case for federation?
- Can this be handed through shared context?
- -or- Would you just send a GraphQL request to the Product service for prices from the resolver?
I’m not sure this is even a case for federation, but I was thinking about all of the use cases for teams who work in complete isolation. Federation gracefully handles every other use case that came up, so I though this may be in the ballpark.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:16
- Comments:8 (1 by maintainers)
@MoonTahoe (👋 Alex!) This is a really great question 👍
The tldr; is this isn’t supported right now 😭
The exciting answer is this is on the roadmap 🎉 This is what it would look like:
A couple things introduced here (that will come in multiple releases):
@internal
directive. This will probably come first in the scheme of things. Internal will allow for hiding fields from the overall schema that the client can consume.@requires
support when used on a base type. This will come a little bit later because it complicates the query planner a good bit 😆. Ultimately the query plan would be something like this:I have the same problem, but with a Mutation that requires some extra data for checking some stuff, I tried to find some pretty solutions in the blog and the documentation, but I didn’t find anything so far. In this case, we will decide to use
graphql-request
pointing to another graphql service. The question will be:I will glad if someone Can add some inputs or experiences how we must resolve these situations