-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GraphQL Mutations #966
base: dev
Are you sure you want to change the base?
GraphQL Mutations #966
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #966 +/- ##
==========================================
- Coverage 81.75% 81.70% -0.06%
==========================================
Files 184 188 +4
Lines 15969 16454 +485
==========================================
+ Hits 13056 13443 +387
- Misses 2913 3011 +98 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left some specific comments but there are a few general things that I think will need updating in this too.
- I know it was my idea but I think wrapping the mutations in a project to implement the permissions was actually not a great idea. It means that we can only restrict to full write permissions but some mutations like cohorts and comments actually allow for a lower level of permissions. After thinking about it some more, I think the best approach is to remove all the permissions checks from graphql and only have them in layers.
- The return values of mutations need to be consistent and should return the thing that was updated/created. This makes the mutations a ton easier to use in the frontend as you don't need to make an extra request to get the updated item. It's also important that they return the exact same type as if you were to request the item, not a type like
AssayUpsertType
. This is due to the way Apollo handles its normalized cache. For things like deletes we can probably just return True or None, just need to settle on a standard and stick with it. - Also need to be consistent with inputs, it seems like in most cases the mutations are accepting a single input type, or in some cases the id and an input type. I think that's fine but we should be consistent and make sure that we don't have mutations that have a ton of inputs.
A continuation of #686 - created this fresh branch because there were too many merge conflicts to deal with. Feedback and changes requested in #686 should be incorporated here.