Resolve an External Entity with Apollo Federation
Federated services can also resolve external entities using references. When a service resolves an external entity, it only needs to return a reference to that entity. These references are resolved by the service that defined the entity with a special resolver called __resolveReference.
Instructor: [0:00] I'm here looking at the code base in the lift service and let's say we wanted to add a trail access field to the lift type. This would allow our users to list all of the trails that are accessed by a specific lift.
[0:11] We'll need to add a lift resolver key here and a trail access resolver to that. The parent object is going to be the lift.
[0:21] Each lift record has an array of related trail references, so I'm going to go ahead and map over those. In each reference is a trail ID. I'm going to go ahead and add a type name so that we all know that we're resolving trail types.
[0:37] I want to return the ID or the reference for each trail. We need to restart the gateway. This means I can create a query for all lifts and find the connected trails that live off of each lift.
[0:53] In the results here, I can see the ID, the reference to each trail. What if I asked for more info about the trail? The lift service cannot provide that info, so we get an error. What I have to do is allow the trail service to resolve trail types through a reference.
[1:14] I can do this within the trail service. All I need to do is add an additional resolver to the trail type. This resolver is called resolve reference. It can be used to look up trail objects based on their reference, the trail ID.
[1:29] This resolver will receive the reference and I can use it to find the trail. If any external service returns the trail, we can resolve the rest of that trail data here and allow our users to ask for any fields on the trail that they want.
[1:48] In this case, the lift service is going to return the reference ID field and the trail service is going to do the rest. We can see here that our query is working, so we are getting the related trails.
[2:04] Let's take a look at the query plan. The query plan shows us how the gateway orchestrates this request. It's going to send downstream requests in sequence.
[2:14] First, it sends the all lifts query. We can see here that we're only resolving the ID of the trails accessed by each lift. The next request is sent to the trail service. We find the trails by their reference, the ID, and resolve any additional information about each trail.
[2:34] Finally, the results are flattened and combined into a single response.
Yes, they gateway interacts with special queries on the service. Right now, it's only JavaScript, but it is possible to implement your own federated service in another language. Apollo has published the specification: https://www.apollographql.com/docs/apollo-server/federation/federation-spec/
Thanks for this Alex much appreciated.
Is there a guide for doing the same with Mutations and Subscriptions?
This is neat!
Question is, does the individual services have to be federated first for you to use them on the gateway? If yes, do we have equivalent packages for other languages like python to do the same.
For instance, I have multiple services written in python using graphene and I have a gateway written in JS using apollo server and I am currently using schema stitching and remote methods and to build the gateway. I'd like to rewrite the gateway to use federation but I wonder if I can do that given my stack?