Check out the resolvers/User.ts file. Here you'll find the __resolveReference function. This function's responsibility is to take in a representation of a User instance from the router. The router typically will provide an object with two properties: __typename, and whatever fields the type designates as its keys. In our case, that's the id field. So, our __resolveReference function might receive something like the following.

{ __typename: 'User', id: '1'}

From here, it's the job of the __resolveReference function to identify the corresponding User instance within its own domain: essentially, this means that our messages subgraph takes in this information, looks up the corresponding user in its database, and returns it. It's kind of like "making sense" of the user within the context of our messages subgraph!

But we'll also see that our __resolveReference function is doing a bit of extra work here.

__resolveReference: async ({ id, ...attributes }, { dataSources }) => {
  const user = await dataSources.db.getUserDetails(parseInt(id))
  return { ...attributes, ...user  }
}

The function extracts the id field from the representation and uses it to locate the corresponding user in its database. But we're also including the remaining properties sent by the router here as attributes, which we combine with the located user and return from the object.

We do this because we're about to expect more data from the router: specifically, we're going to ask for the isLoggedIn and lastActiveTime fields from the accounts subgraph. The router will fetch these field's values, and include them on the entity representation it passes into the messages subgraph.

So in reality, our entity representation will look something more like this:

{ __typename: 'User', id: '1', isLoggedIn: true, lastActiveTime: "Date" }

While we don't need the isLoggedIn and lastActiveTime fields to figure out which user we're talking about in the context of the messages subgraph, we DO want to make those properties accessible to our other resolvers (specifically, the isOnline resolver!). So, we'll need to include those extra attributes on the object returned by __resolveReference.

The directives @requires and @external are federation-specific - meaning we can't apply them in any old GraphQL schema file. If you scroll up to the top of the file, you'll see a line importing a version of Federation along with three directives we're putting to use here: @key, @requires, and @external! If we wanted to include other directives on our types and fields, we would first import them here.