Support Relay

[LegNeato]

Looks like Relay has a thin layer on top of GraphQL. Would adding (optional?) Relay support be in scope for juniper?

[bbqsrc]

I have started working on relay support, implementing the Relay Cursor Connections Specification specification here.

[kaushalyap]

@bbqsrc can we now use relay with Juniper? any updates?

[LegNeato]

FWIW, I found https://github.com/bbqsrc/juniper-relay. @bbqsrc can speak to the state of it of course.

[MonsieurMan]

There is a specification page about the assumptions Relay makes of a GraphQL server. https://relay.dev/docs/en/graphql-server-specification, work could begin from there.

Those three points are further detailed and linked at the end of the page, https://relay.dev/docs/en/graphql-server-specification#further-reading:

• Global unique IDs + a few more things
• Connection modeling of paged entities, the same way github and others models pagination for entities.
• Using a mutationID for mutation inputs

From my understanding, any implementation of a GraphQL server can work as a Relay server, you just have to check a few other things. There is maybe an opportunity to check them at compile time with Rust but this is not to be added directly into juniper IMO.

[UkonnRa]

So any progress on Relay?

[MonsieurMan]

@UkonnRa see my comment above. You can use it, you just have to check a few things manually and to conform to the three specs I linked to.

[davidpdrsn]

I wonder if the relay additions could be a separate library built on top of juniper and not necessarily something that is built in 🤔

[MonsieurMan]

IMO, if it exists it really should be separate of juniper. Relay is a spec on top of GraphQL, so should it be for juniper and a Relay layer on top of it. Le ven. 10 janv. 2020 à 2:01 PM, David Pedersen <[email protected]> a écrit :

…

I wonder if the relay additions could be a separate library built on top of juniper and not necessarily something that is built in 🤔 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#42?email_source=notifications&email_token=ADEAHRU5SVCNPXT42MYDQDTQ5BWTHA5CNFSM4DIVMG22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIT3BBA#issuecomment-573026436>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEAHRQPTCPOGUVIN2SDPT3Q5BWTHANCNFSM4DIVMG2Q> .

[davidpdrsn]

I guess that means someone can build a library crate for relay support?

[Asone]

Just for information, digging on with Github search i found an implementation that seems to work made by @dyedgreen on a rust project he made. The implementation can be found here.

I don't know if he intends at some point to publish this as a separate crate, but meanwhile it could be useful to anyone that would like to use relay pagination.

Also, his code uses the implementation so it provides a good example on how to use it

[dyedgreen]

If people find it useful, I could try to update the library if necessary and publish it as a stand-alone crate.

I made this a while ago, but iirc it’s mostly just a trait that you can implement which then gets plummed through to the correct Juniper traits.

[Asone]

If people find it useful, I could try to update the library if necessary and publish it as a stand-alone crate.

I made this a while ago, but iirc it’s mostly just a trait that you can implement which then gets plummed through to the correct Juniper traits.

For my own use i just made a copy of your implementation mentioning the source.

However if you intend to publish it as a crate i'd be happy to use it as a dependency 😀.
I can't speak for all but i'm pretty sure people would find it useful as even if it is a few traits and structs, it might be not so trivial to many as no other implementation ( aside of @bbqsrc's one ) can be found on GH.

[dyedgreen]

I've moved the Relay connection package into it's own repo and published that on crates.io. (I also added an async version, so the load closure may be async ...) (cc @Asone)

[IvanRodriCalleja]

How do you support Global ID with Juniper?

having the node query:

node(id: "") {
    id
    ... on Model {
      name
    }
  }

I can't think in a good way to resolve this node query to get the exact model resolver. I have seen in other language implementations that the id has a shape like: model-id an then converted to uuid with that when the node query is requested deserialize that and uses the model to resolve.

How do you implement this resolver?