Add support for Relay refetching (Relay-compliant IDs and the `Node` query)

[rbino]

Is your feature request related to a problem? Please describe. Ash GraphQL implements the Relay Node interface, but Relay refetching mechanism assumes that IDs are globally unique (and, basically, encode enough information to retrieve a specific object given only its ID), while currently Ash GraphQL returns the data layer primary key (possibly encoded if multiple), that even if globally-unique (e.g. UUID) still doesn't contain enough information to target a specific resource on a data layer. Moreover, Relay assumes there's a root Node query .

Describe the solution you'd like It should be possible to use the Node refetch mechanism with Ash GraphQL.

Describe alternatives you've considered Passing define_relay_types?: false (found on a discussion on Discord) doesn't really do much because while it allows you to manually define the node interface, it still doesn't give access to the extension points needed to handle the ID encoding/decoding.

Express the feature either with a change to resource syntax, or with a change to the resource interface I guess this would make sense globally, so I imagine something like:

  use AshGraphQL, relay_ids?: true

I'm not sure if this should be a separate option or should take the values from define_relay_types? in the long run, but clearly it makes sense to have a separate variable until the next major.

This would take care of generating the blueprints to both encode to and decode from the :id field, embedding resource type + primary key informations.

The other aspect of this is that sometimes mutations (also queries?) can take as argument an ID to another object. For that I think that some more separate syntax has to be added explicitly marking the arguments that need to be translated:

update :frobnicate_with_the_foobar, :update, relay_ids: [:foobar_id]

I can try to tackle this if the rough plan sounds good, or let me know if I'm missing some details.

[zachdaniel]

Your plan sounds exactly correct 🤌

[rbino]

@zachdaniel I was circling back around this, and I've realized it probably makes more sense to define this per-resource instead of globally. Absinthe itself requires to add the node macro in front of each object that implements the Node interface.

This would also unlock the possibility of custom ID fetchers (as Absinthe does) if one wants to implement them. The downside of this is that it's a little more verbose.

[zachdaniel]

Hmmm...potentially. I'd suggest we should start with a global version that requires no configuration, and then allow for overriding if necessary.