Support nested link and multiple link

Here is how I would(do) do it:

type User {
    id: String! @id
    name: String
    isMemberOf: [Member] @hasInverse(field: user)
    ownsGroups: [Group] @hasInverse(field: owner)
    authoredPosts: [Post] @hasInverse(field: user)
    postsLiked: [Post] @hasInverse(field: likes)
}
type Group {
    id: String! @id
    owner: User
    members: [Member] @hasInverse(field: group)
    posts: [Post] @hasInverse(field: group)
}
type Member {
    id: String! @id
    user: User
    group: Group
    is_owner: Boolean
    level: Int
    last_publish_at: DateTime
    last_query_date: DateTime
    ...
}
type Post {
    id: String! @id
    user: User
    group: Group 
    likes: [User]
    ...
}
{ queryUser { isMemberOf { group { id } } } }
{ queryUser { authoredPosts { id } } }
{ queryUser { postsLiked { id } } }

But then you couldn’t answer the above questions separately. They could only be answered always as either I liked this post or I created this post, I don’t know let me go look at it.

On a side note, You can create some wonky relationships like this:

posts: [Post] @hasInverse(field: user, field: likes)

BUT!! That may cause more problems down the road, FYI.

To chase the rabbit all the way to it’s whole… You may get a benefit of Unions to help with answering the questions show me the posts I have liked or I have authored. It might look a little strange, but would be interesting to see flushed out and used:

type User {
  ...
  postsLiked: [PostLiked] @hasInverse(field: user)
  postsAuthored: [PostAuthored] @hasInverse(field: user)
  postsLikedOrAuthored: [PostLikedOrAuthored] # @hasInverse(field: user) # still unsure of how Unions are going to use hasInverse.May have to manually link with JS-hooks
}

union PostLikedOrAuthored  = PostLiked | PostAuthored

type PostLiked {
  id: ID!
  user: User
  post: Post
  likedAt: DateTime
}

type PostAuthored {
  id: ID!
  user: User
  post: Post
}

type Post {
  id: ID
  author: PostAuthored @hasInverse(field: post)
  hasLikes: [PostLiked] @hasInverse(field: post)
}

IMHO, I don’t think you are to that point yet. All of this can be achieved with a better designed schema. I wouldn’t turn to mixing DQL in with custom queries until you absolutely have to. One of the main reasons, is that you lose two of the best features of having a graph database if you use a custom DQL query/mutation. 1) The ability to do deep nested queries almost endlessly and 2) The ability to only get what you need. Right now with a DQL custom query you would have to get every field as deep as could every be wanted and return it to every request, but then sometimes you only want just the root id… whoops, we just traversed a thousand+ nodes for a single id. It breaks the rules of only getting what you want, and only touching what you need.

2 Likes