RFC: Object Identification

[phryneas]

Opening this as a PR against the fork first, to get some feedback before I open it as a PR against the WG repo

[BoD]

Hmm I dont understand this sentence, could you clarify?

[phryneas]

You can't have a schema that ever returns

{ "__typename": "Person", "__id": "5" }

and then from time to time also

{ "__typename": "Person", "__id": null }

Either all Person-type objects ever returned by a schema have an __id of null, which means that the server can't tell us to identify these objects, or they have to always have an __id that's non-null, which means that all Persons are identifiable.

Allowing this to be mixed will cause all kinds of weird problems down the road. Either a type is identifiable/normalizable or it isn't.

[BoD]

👍 I think that was clear with the previous sentence The field is of type ID and for each individual type, the field must either always return a non-null value or always return null., but the one after that I'm having trouble parsing it. Is it saying the same thing or something more? Maybe it's just me!

[phryneas]

I was trying to clarify it, but it seems I made it worse instead 🤣 I'll remove that sentence and see what feedback I get in the actual RFC process on wording it better.

[BoD]

I guess this could also be a topic for the capabilities RFC.

Also I think Feature detection may be confusing - it could be understood to mean whether the server supports __id at all, whereas here we mean whether some types have ids.

But I don't have a great alternative 😬. Maybe Presence of globally identifiable types?

[phryneas]

Yeah, the capability would be more "this server uses a version of the spec that allows you to query __id", while this would be more along the lines of "while it supports the spec, nobody ever took the time to implement it in the schema, so you don't even have to try in the future".

[phryneas]

I like Presence of globally identifiable types more, gonna change that :)

Suggested change

	### Feature detection
	### Presence of globally identifiable types in the schema

[BoD]

__id is specified as ID and overridden as ID! - I believe this makes sense (ID! being a subtype of ID) but potentially a can of worms 😅

[phryneas]

If it's an entity, it's identifiable. This goes hand in hand with that requirement of "for a type, __id is either always null or never null`

[phryneas]

In the world of graphql-js for example this could be "if you define a resolver/calculation function for __id, it may never return null and we implicitly apply __Entity to the type.