Experience Report for Feature Request
What you wanted to do
Implement both a work around for field level auth and also prevent duplicates edges while using this workaround.
There are two main types, User and Post and we need to allow a user to vote on a post and only allow a single vote per User/Post. We want to use an edge not an int to prevent anyone from just randomly updating the vote count to any number. Every vote represents a single user.
type User {
username: String!
posts: [Post] @hasInverse(field: "author")
voted: [Post] @hasInverse(field: "votes")
}
type Post {
id: ID!
title: String! @search
author: User!
votes: [User]
}
This model didn’t work because while it attains unique votes a user has to be allowed to edit either the user or the post to cast a vote. The user should not be able to update their own user, nor should they be allowed to update someone else’s post.
type User {
username: String!
posts: [Post] @hasInverse(field: "author")
voted: [Vote] @hasInverse(field: "votes")
}
type Vote {
id: ID!
on: Post! @hasInverse(field: "votes")
by: User!
}
type Post {
id: ID!
title: String! @search
author: User!
votes: [Vote]
}
This protects both the User and the Post from being maliciously updated, but this introduces the other problem of not being able to restrict a user from voting multiple times on the same post.
It is impossible to meet both of these conditions without writing a lambda mutation and trying to avoid lambdas as much as possible because of their limitations (can’t pass a field set, potential lag at scale)
What you actually did
Realized it cannot be done without one of the below proposals… so created this feature request with actual use case.
Why that wasn’t great, with examples
No way to create the model needed for this without also needing to write lambdas with custom mutations. I want to use only the auto generated mutations/queries with auth rules to achieve this use case.
Any external references to support your case
Basically need to create relationship like a SQL pivot table with a 2 column unique key constraint.
It is a common use case to like, vote, react, etc on other nodes without having access to update either node directly.
This would be resolved if we had ONE of these:
- GraphQL Filter on edge/aggregate counts
- Pre-Add Auth rules. This would allow a check for an existing relationship before adding another new one.
- Field Level Auth
- Or another work around with Unique Constaint across multiple fields