Announcement: Ariadne-Relay package available

[markedwards]

Update (2021-05-25):

Ariadne-Relay is now available: https://github.com/g18e/ariadne-relay

pip install ariadne-relay

Ariadne-Relay provides a toolset for implementing GraphQL servers in Python that conform to the Relay specification. Its built on top of Ariadne, and aims to make implementing Relay feel just like the rest of Ariadne.

It will stay pre-release until test coverage is complete, and ideally until it gets some adoption and feedback. Please post in Ariadne-Relay issues and discussions if you have any feedback.

---

@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.

[bartenra]

@markedwards Did you ever finish the draft implementation?

[markedwards]

I did in the sense that I got it working, but I put it aside after that. I am actually about to return to it though, and put it to use. I would expect it to be stable enough to share once that's done.

I actually wonder if it makes sense to offer this to ariadne.contrib instead of creating a standalone project, especially since the plan is to separate ariadne.contrib into its own package?

[rafalp]

It should be a separate package with its own maintainers, releases and documentation. :)

[markedwards]

Fair enough. :-) I wasn't sure what the scope of contrib was expected to be as a separate project. But I appreciate you guys want to prevent scope creep in Ariadne.

Let me revive the code and get it to a satisfactory point, and then I will create an initial repo for it and request comments. I would probably call it ariadne-relay.

[markedwards]

I have a codebase now which seems to be fairly stable and achieves my goals. It implements support for connections and Node types, and I’ve tried to make it feel like a first-class part of Ariadne. I don’t have anything for mutations because it’s not clear to me what is needed there, if anything.

I plan to post an ariadne_relay repo soon (shooting for the weekend), and an accompanying alpha release on PyPi.

[sebastiandev]

Excited to see it. I'm considering ariadne for a re-write of one of our apps and this would be a big advantage against tartiflette (which I'm already using, but struggling with relay)

[markedwards]

Sneak preview, the code looks like this:

from ariadne_relay import RelayQueryType

query_type = RelayQueryType()


@query_type.connection('foo')
def resolve_foo(_: None, info: GraphQLResolveInfo, connection_args: ConnectionArguments) -> list[Foo]:
    return [Foo(), Foo(), Foo(), Foo()]

A connection resolver can return any object that conforms to SizedSliceable from graphql, and it will be turned into a connection structure. There's a lot of customization that can also be done, but the simple case is the above.

[markedwards]

ConnectionArguments is a NamedTuple that has the first, last, after, before from the query, in case they are useful. But there's no requirement to handle them in a normal case.

[sebastiandev]

you might want to consider the n+1 issue. This is an example from graphene. I have created this pr that was never merged, addressing the problem graphql-python/graphql-relay-py#27.
Its mostly about not iterating the whole iterator or doing len(), but rather try to get n+1 to determine if there are more results or not.

[markedwards]

The implementation uses connection_from_array() from graphql_relay in its default connection factory, but it is easy to override this with a factory of your choosing:

@query_type.connection('foo', factory=DjangoConnection)
def resolve_foo(_: None, info: GraphQLResolveInfo, connection_args: ConnectionArguments) -> QuerySet[Foo]:
    return Foo.objects.all()

It’s also possible to set a default factory so you don’t have to override everywhere.

At the moment, I’m leaving it up to the developer to implement whatever alternative factory works for their case, although I’m including a SnakeCaseConnection for use in conjunction with ariadne.snake_case_fallback_resolvers, as well as a ConnectionProxy variation for passing through already-formed connections from another GraphQL endpoint. I expect to add stock factories to handle common scenarios like ORMs, with help from contributors like you :-). However, I have tried to make it very straightforward to customize the connection factory, because I think that most serious deployments will want to do so.

[markedwards]

Ariadne-Relay is now available: https://github.com/g18e/ariadne-relay

pip install ariadne-relay

It will stay pre-release until test coverage is complete, and ideally until I get some adoption and feedback. Let me know if you have a chance to take a look!

Do you think it makes sense to post an announcement separate from this thread? Or maybe change the title of this thread?

[otryshko]

@markedwards the thing is that I want to provide real pagination. I.e. there are 10 rows broken into 2 pages (rows with ids 0-4 and 5-9). First, client gets the first page (afterCursor: None, first:5) and stores endCursor (which should be the base64('{typename}:{row4's id}')). Then it is going to request the second page passing in (afterCursor: lastEndCursor, first:5). Backend would have to decode afterCursor and pass it to the where condition to Mongo (WHERE rowid > {afterCursor.rowId} LIMIT {first}).

But in order to populate hasNextPage/hasPreviousPage we need to understand if there are elements before and after the requested range. In order to do so, we'd have to "pad" the range requested (change WHERE to >= instead of > and increment first = first + 2).

We will get requested range plus potential padding elements (right before and right after the range) and use the existence of the pads to deduct hasNextPage/hasPreviousPage values, and then chop pads off before returning data to the client.

Does it make sense or I'm over complicating things?

[markedwards]

@otryshko This is what happens in the Django example. Django uses the slice to determine how to filter the query to the requested page, and the query isn’t performed until the data is enumerated. But this might not fit the Python Mongo API. If the Mongo object doesn’t implement __getitem__ and __iter__, then you either have to write a wrapper that does, or build your own connection factory that doesn’t make these assumptions.

Are we talking about PyMongo here or something else?

[otryshko]

@markedwards I'm using mongoengine but I'm open to switching to PyMongo if it makes things easier.

[markedwards]

@otryshko just from a brief look at mongoengine, it looks very Django-like. I would wager you could basically use my above Django example and return Foo.objects from your connection resolver where Foo is your mongoengine Document subclass. Yes, this will result in an additional query from the count(), but I would start with that and then consider a refinement to eliminate that if you really think you need to. If mongoengine works the way I think, you will only be querying the objects in the requested page.

[otryshko]

@markedwards thank you - let me try it!