Add federation metadata extension methods and attributes

[Shane32]

Part 2 for #3921

Does not include the directive definitions

• Add documentation
• Scope extension methods to the proper types
• Add url links to Apollo docs

[gao-artur]

A lot of work for analyzers 🥴

[Shane32]

I've got some ideas....

[Shane32]

Ok the extension methods and attributes should all be scoped to the appropriate targets.

[Shane32]

Have not yet added url links within the xml comments

[gao-artur]

This extension is useful to define compound or nested field keys. But I guess a single field as a key should be the most frequently used. Then need another extension based on IFieldMetadataWriter

[gao-artur]

Actually, FieldBuilder implements IMetadataWriter, so it works for all cases.

[gao-artur]

But it doesn't implement IComplexGraphType so it doesn't work...

[Shane32]

I don't follow you. @key is only valid on an object or interface, which is what IComplexGraphType is.

directive @key(fields: FieldSet!, resolvable: Boolean = true) repeatable on OBJECT | INTERFACE

https://www.apollographql.com/docs/federation/federated-types/federated-directives#key

[Shane32]

As is implemented now, these methods simply add directives to the schema. They are not 'intelligent'; for example, you can't put [Key] on a field and have it automatically add the proper directive to the graph type. While that's possible, it's not the current design.

So for @key, you can do @key(fields: "id name pricing { id }") by specifying this.Key("id name pricing { id }") on the graph type.

[Shane32]

I see. Then, it can be enchantment in 8.1 if you prefer.

Yes let’s just get a workable version pushed out

Or at least merged in so we can review what further enhancements we want to make

[gao-artur]

Btw key on interface is only supported sine v2.3. Adding it now will require adding version detection/configuration + validation.

[Shane32]

Yeah, we need to work on that (not yet in #3921 )

[Shane32]

Generally, I'm planning to have the proper directives added based on the version. Schema validation will already match up the applied directives to configured directives. So it will catch this error if it's the wrong version.

[Shane32]

having one target IObjectGraphType and the other target IInterfaceGraphType

Sounds better than implementing an analyzer to prevent incorrect usage. We can probably use the [AllowedOn<>], but I'd prefer strongly typed API over static analysis.

I’ll make the change

Done