Support for federated schema.

[Pruxis]

This does not make that augmented schema's automaticly support federated schema's.
But then again I don't think anyone who uses augmented schema's will be using federation.

Example usage:

__resolveReference: async (foo: { id: string }, context, resolveInfo) => {
  resolveInfo.returnType = 'Foo';
  const result = await neo4jgraphql({}, { id: foo.id }, context, resolveInfo);
  return result;
}

[Pruxis]

A bit late, but as promised my PR @johnymontana

[Pruxis]

Also related to #260

[emregency]

@Pruxis Great work! That’s a tough one to tackle. I did not have the chance to try the solution but the change effort for implementation looks affordable.
FYI @Pruxis, I do use augmented schema for the convenience of the relationship mutations generation. I do believe that as Neo4j will become one of the de facto dB for cloud applications, many will appreciate the federation with augmented schema to bootstrap their first project like Movie ratings where Movie related images are queried from Pexels/Unsplash for example.

What do you think?

[Pruxis]

We never use them, but I can see that some companies see value in it.

However implementing it for augmented schema's is a whole lot more complicated as you are required to check the entire schema on what types you are extending, with what types.

[emregency]

I do agree that it’s tough with augmented schema. Considering the fast pace in the evolution of the Apollo’s federation library (almost a version a day) and the changes they may introduce, your solution is great I think. I will be implementing it next week.

Thanks again @Pruxis

[johnymontana]

Great, thanks @Pruxis - we'll have to figure out what breaks with the augmented schema and how to fix it, but this looks good initially