Proposal: ariadne-relay

[markedwards]

@rafalp and @patrys, I dropped a comment on #188 a couple of weeks ago, but I think it might have gone under the radar since that issue is closed, so I'm going to make a more formal proposal here.

I've already built a quick-and-dirty implementation for Relay connections, based on a decorator that wraps an ObjectType resolver that emits a Sequence. The implementation resolves the connection using graphql-relay-py. It works well, but its too specific to my case to be offered as a generalized implementation.

I agree with the assessment in #188 that the right path forward here is for there to be an independent ariadne-relay package. It seems reasonable to build it on top of graphql-relay-py so it is synchronised closely to the reference Relay codebase. I'm willing to take ownership of this project, but I want to introduce the approach I have in mind here for comment, prior to doing further work.

Proposed implementation:

• ariadne-relay will provide a ConnectionType class, as a subclass of ariadne.ObjectType, which takes care of the boilerplate glue between an iterable/sliceable object returned by another resolver and graphql-relay-py. This class will have a set_count_resolver() method and a count_resolver decorator to allow for control over how the count is derived.
• ariadne-relay will provide a NodeType class, as a subclass of Ariadne.InterfaceType, which will help with the formation of ID values, leveraging the methods in graphql-relay-py. This class will have a set_id_value_resolver() method and a id_value_resolver decorator to allow for control over how ids are derived.
• I haven't worked yet with graphql_relay.mutation so I'm not sure how that might be leveraged, but at a glance it seems like it should be possible to do something useful here.
• ariadne-relay will adhere to Ariadne's dev and coding standards, so it stays a close cousin.

Does this seems like a reasonable basic direction? It seems from #188 that you guys have put a bit of consideration into this already, so perhaps you have some insight that I'm missing?

[rafalp]

Make sure you'll share the word on spectrum for more coverage: https://spectrum.chat/ariadne

[rafalp]

Does this seems like a reasonable basic direction? It seems from #188 that you guys have put a bit of consideration into this already, so perhaps you have some insight that I'm missing?

Don't have a horse in this race. My experience with relay was through Graphene and examples in "Learning GraphQL" book that was giveaway on GraphQL Summit, but I've never used Relay on client side myself, and I wasn't biggest fan of conventions enforced by Graphene.

Perhaps once you have the repo up I'll be able to be more of help. :)

[markedwards]

Thanks @rafalp. Once I get an first-draft implementation that I'm happy with I'll publish it on spectrum for comment. Do you mind if I leave this thread open for a week or so in case there are other reactions?

[markedwards]

I dug in a little bit to this today. I don't think the idea I had to provide a ConnectionType will work, because the connection has to be constructed by the parent field. So, update to the proposal:

• ariadne-relay will provide a RelayObjectType class, as a subclass of ariadne.ObjectType, which will add a set_connection() method (and related methods). This will function similarly to ariadne.ObjectType.set_field(), but will take care of the boilerplate glue between the return of the provided resolver and graphql-relay-py.

There are two slightly tricky design challenges with this:

1. The implementation needs to support returning the count, in addition to the data, to properly support cases like Django where calling len(data) is not desirable.
2. Downstream resolvers might need access to the original data object, in addition to the Connection object. For example, to support adding a totalCount field, which returns the unsliced length of the data.

I'm leaning towards using a RelayConnection object to support these things, which can either be returned by the resolver, or which will be created as a wrapper if just the data is returned. I'm not totally happy with the design of this yet, though.

Short story, it seems like this project can work, but it's a bit involved.