graphback icon indicating copy to clipboard operation
graphback copied to clipboard

Many-to-many relationships have strange selection set structure

Open lastmjs opened this issue 5 years ago • 1 comments

If I have a many-to-many relationship, I have to use a join table. The join table becomes the type of the side of the relationship that I care about, which then has each member of the many-to-many relationship. I would much rather just have the type of the side of the relationship that I care about be the direct and only type. If I have a many-to-many relationship from Users to Posts, I want the posts field on Users to be an array of Posts, not an array of objects with a post and a user.

lastmjs avatar May 29 '20 17:05 lastmjs

It would be great to have a simplification of many-to-many relationships, as discussed here: https://github.com/aerogear/graphback/issues/936#issuecomment-665267133

Also, the mutations for relationships in general I think could be improved. I think it's unnecessarily complicated to have to expose the _id field for relations when updating or creating entities. We shouldn't have to think in terms of id's like that when handling relations at the schema level.

Prisma had a really nice way of doing this, it looked something like the following. Imagine you have a user and a blog post, and you want to create a relation between them:

The user has already been created, and has id: 1 The blog post has already been created, and has id: 2

mutation {
  updateUsers(input: {
    blogPost: {
      connect: {
        id: 2
    }
  }
}

I'm not saying the way they did it was perfect or could not be improved, but it's more declarative. Also, this could work for many-to-many relationships as well. Right now, for many-to-many relationships you have to create a new entry in a join table to connect two entities. It would be much simpler to use syntax like the above.

lastmjs avatar Jul 28 '20 20:07 lastmjs