chore: rfc foundation for @openfed__prerequisite #1429
Conversation
| directive with the `resolvable` argument either omitted or explicitly set to true. | ||
|
|
||
| ### The fields input | ||
| The `fields` input is type `openfed__InputSet!` (henceforth simply `InputSet`). |
There was a problem hiding this comment.
I am not convinced the name of this input is best. Some other potential ideas:
MappedFieldSetMapSetInputToFieldSet
There was a problem hiding this comment.
I think that InputToFieldSet is too verbose. I personally like MappedFieldSet
There was a problem hiding this comment.
Or you can make it clear that it's specific for openfed__ResolveEntityInput by calling it ResolveFieldSet
| ```graphql | ||
| type Mutation { | ||
| updateEmail( | ||
| id: ID! @openfed__prerequisite(resolveEntity: { typeName: "User", fields: "id" }) |
There was a problem hiding this comment.
If I'm understanding correctly, you have to provide the key fields, and then the rest of the fields get fetched and provided for you by the Router? Do the non-ID fields get stripped out of the composed schema? Otherwise I imagine this would be confusing and people would try passing in these fields.
I'm not totally following the use case — if I want to update the email, why would I fetch the email from the User subgraph? Don't I want to overwrite that value with a new email?
There was a problem hiding this comment.
You want to update an email on a user. How do you know that user you're trying to update with the input is a valid user?
| Cosmo will produce an error and the operation will not be committed. | ||
|
|
||
| ### Potential discussion points | ||
| - Multiple entities (batching) |
There was a problem hiding this comment.
This seems very important. Is this API intended to only work for mutations or is this usable for queries as well?
| This means that entity reference is valid and the operation cannot proceed. | ||
|
|
||
| ### Entity Representation Call returns null | ||
| If the entity representation call is unsuccessful, null will be returned. |
There was a problem hiding this comment.
Null will be returned by what / to what? In general, I think a better strategy is to pass the error to the subgraph and allow it to read the error and determine how to proceed. Some errors on some fields will be fail open, and others will be fail closed. IMO we should allow the "client" to decide how to handle failures.
There was a problem hiding this comment.
If the entity resolver cannot match an entity for the key(s) provided, it returns null.
There was a problem hiding this comment.
What if it matches, but some of the fields return errors?
There was a problem hiding this comment.
I'm not sure what you mean. This is an entity representation call like any other. We just provide indirect access to it through the same subgraph.
There was a problem hiding this comment.
I think there is some confusion here. This directive validates an entity. It does not perform across-subgraph calls. You provide the primary key fields and check whether it matches an entity.
The functionality that I think you're describing is something else. This RFC is currently on the sidebench while thinking about what and how we'd like to address injection/inter-subgraph resolutions.
There was a problem hiding this comment.
Got it. If you do intend to work on this more it would be helpful to add a couple examples showing the actual requests the Router would make to each subgraph including the request body to better understand the call patterns and intent.
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Motivation and Context
Checklist