Road towards relay compatibility

[hardchor]

N.B.: Moved this from RisingStack/graffiti#7

Just putting some thoughts down of currently missing features:

Unique Object IDs

Relay wants to be able to (re-)fetch any object in the graph by a unique ID via a root query named node:

node (id: "user123") {
  id
  name
}

Relay methods: fromGlobalId/toGlobalId
See: https://github.com/relayjs/relay-starter-kit/blob/master/data/schema.js#L115

Pagination

On the query side, relay requires first and after arguments (as well as last and before for backwards pagination):

users (first: 10, after: "user123") {
  edges {
    cursor
    node {
      id
      name
    }
  }
  pageInfo {
    hasNextPage
  }
}

• edges: describes the collection (https://facebook.github.io/relay/graphql/connections.htm#sec-Edge-Types)
  • cursor: would be the unique ID discusses above
  • node: the box-standard field selector
• pageInfo: an object with meta-data about the current page (https://facebook.github.io/relay/graphql/connections.htm#sec-undefined.PageInfo)
  • hasNextPage
  • hasPreviousPage: for backwards pagination

Also see: https://facebook.github.io/relay/graphql/connections.htm

Mutation

TBC

Fragment support

Connections

I expect graphql-relay-js to help us out with the more intricate details

I hope we can work towards relay compatibility. Please let me know if this is more appropriate for an adapter, e.g. graffiti-mongoose

[hardchor]

@hekike @gergelyke Are you guys still developing this? Feels like the project is already dead before it even got off the ground...

[gergelyke]

hi @hardchor,

thanks for raising them! in the past weeks sadly we did not have the time that this project would deserve - could you help us out and send a PR with these?

[hardchor]

I'm still at the crossroads which route to take:

• mongo - mongoose - graffiti or
• SQL - bookshelf - graphql-bookshelf

Before I invest any significant amount of time, how likely are you to continue this project, i.e. are you going to be using it in production apps or is it all still a bit in the air?

Also, mutation is a biggie - whilst not being a completely blocker for this ticket, not having mutations would certainly leave a big gap in any Relay integration. https://github.com/RisingStack/graffiti-mongoose/milestones/support%20mutation%20queries

[gergelyke]

We definitely want to use it in production applications - with that said, I would go for finishing up one graffiti adapter implementation first, this one, so we will have a reference when working with others, like bookshelf.

What do you think?

[hardchor]

Totally agreed. Could have a bit of a catch up on Skype if you fancy.

[gergelyke]

in which timezone are you in? let's find a time which can work.

cc-ing in @hekike

[hardchor]

GMT. Added you both to https://gitter.im/hardchor/graffiti

[parkan]

Given that the cursors are specified as opaque, I don't see why cursors and globally unique IDs need be the same. The global id could take the format of $collection:$_id and cursors could be $_id if indexing into a collection (data structured with parent references) or maybe even numerical offsets if indexing into a subelement of child references.

EDIT: globalIdField used here works nicely, wrapping the same information https://github.com/RisingStack/graffiti-mongoose/pull/27/files#diff-55c36325e001f1671db3cf8a5b686a2aR59

[ghost]

@parkan They are opaque, but as you already noted, encoded as a globally unique ID (just a simple base64 encoding)

[tothandras]

We have added the node(ID!) endpoint and pagination support and we are currently working on the mutation support. The new version is published on npm (^3.0.0). Your feedback is welcome!

[gergelyke]

I guess we can close this, right?

[hardchor]

I think we're still some way off full relay compatibility:

• viewer endpoint
• mutations

[tothandras]

The viewer endpoint and mutations have already been added. Check out the latest version!