-
-
Notifications
You must be signed in to change notification settings - Fork 821
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
createRequest
with transforms API
#724
Conversation
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.
Awesome stuff 👍
src/stitching/delegateToSchema.ts
Outdated
fragmentName => info.fragments[fragmentName], | ||
), | ||
info.operation.variableDefinitions, | ||
export function createBatchOperation( |
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.
We can probably name it createDocument
. createDocument
was never a public API and this probably should be.
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.
What do you think about createOperation
? Since I think it's good to return the variables too.
src/stitching/delegateToSchema.ts
Outdated
}, | ||
transforms?: Array<Transform>, | ||
): FetcherOperation { | ||
const roots = Object.keys(rootDefs).map(key => { |
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.
Question here is whether we should auto-alias stuff or if we should expect user to alias themselves. I guess latter. Data-loading API can then alias by itself.
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 was thinking users should add aliasing themselves:
{
'user1:node': [{ id: 1 }, ...],
'user2:node': [{ id: 2 }, ...]
}
But obviously with the API you specified below (:
src/stitching/delegateToSchema.ts
Outdated
transforms?: Array<Transform>, | ||
): FetcherOperation { | ||
const roots = Object.keys(rootDefs).map(key => { | ||
const [args, info] = rootDefs[key]; |
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.
Ok, this starts getting very complicated. How about this as a signature for rootdefs:
rootDefs: Array<{
alias?: string,
fieldName: string,
args?: { [key: string]: any },
info: DocumentInfo
}>
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.
Also extract it to a type.
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.
Yeah that works for me!
src/stitching/delegateToSchema.ts
Outdated
targetOperation: 'query' | 'mutation' | 'subscription', | ||
rootDefs: { [key: string]: [{ [key: string]: any }, { [key: string]: any }] }, | ||
graphqlContext: { [key: string]: any }, | ||
documentInfo: { |
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.
Extract this to a type.
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.
Disregard that. Let's always pass info through rootDefs. Having two sources of truth is confusing.
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.
Also you don't have fieldNodes
in documentInfo
atm.
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.
It's kinda complicated. You might need to add fragment aliasing. But then we probably don't want to duplicate identical fragments. Same with variables.
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.
Yeah i always meant for that to be the full info object, but i just created a new type from the fields i was using. I'll update that 😄
src/stitching/delegateToSchema.ts
Outdated
CheckResultAndHandleErrors(info, options.fieldName), | ||
transforms = [ | ||
...(transforms || []), | ||
...roots.map(({ args }) => AddArgumentsAsVariables(targetSchema, args)), |
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.
This will reset a variable counter each time. I think you should have one AddArgumentsAsVariables
, it should be modified accept args lists with fieldName or alias and assign variables to them.
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.
This way we don't need to traverse AST that many times.
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.
@freiksenet do you think that parameter's type should be:
args: { [key: string]: any } | Array<{ fieldName: string, alias?: string, args: { [key: string]: any } }>
?
That seems to be the only way we can support both patterns right?
src/stitching/delegateToSchema.ts
Outdated
transforms = [ | ||
...(transforms || []), | ||
...roots.map(({ args }) => AddArgumentsAsVariables(targetSchema, args)), | ||
FilterToSchema(targetSchema), |
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'm pretty damn proud this still works without any problem :D
- Extract OperationRootDefinition type
src/stitching/delegateToSchema.ts
Outdated
targetOperation: 'query' | 'mutation' | 'subscription', | ||
rootDefs: Array<OperationRootDefinition>, | ||
graphqlContext: { [key: string]: any }, | ||
documentInfo: GraphQLResolveInfo, |
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 left this for now, but let me know if you want me to change this. documentInfo
was a prop i though users could use to define properties that are global to that operation, and do not affect specific root fields. Like fragments, for example.
src/stitching/delegateToSchema.ts
Outdated
return { | ||
query, | ||
variables, | ||
context: graphqlContext, |
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.
Should we return context: graphqlContext
or context: { graphqlContext }
? My original intention was the second because then you can take the return object and pass it directly to a fetcher.
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.
Or should we remove context all together, and just have this function return { query, variables
or { document, variables }
?
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.
Just document and variables I think.
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.
We are nearly there.
- Can you add tests for createOperation? Test it by running
execute
with it. I at least want to see one that has aliases, one that doesn't, different arguments etc. - Could you add API docs for createOperation to schema delegation docs?
src/stitching/delegateToSchema.ts
Outdated
return { | ||
query, | ||
variables, | ||
context: graphqlContext, |
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.
Just document and variables I think.
src/stitching/delegateToSchema.ts
Outdated
}; | ||
} | ||
|
||
export default async function delegateToSchema( |
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.
Pet peeve - could you move default export on top?
As discussed, let's rename it to |
Oh yeah, and you need to export it in |
createBatchOperation
with transforms APIcreateRequest
with transforms API
…ools into apollographql-next-api
@mfix22 so to recap, this is a way to do everything that delegateToSchema does except for actually sending the request, allowing you to do stuff like sending it in a batch? Would this be better done via Apollo Link? Also, looks like there were some PRs around changing how subscriptions are done and similar, would you have a minute to update this if you think it's necessary? |
@stubailo yes. The PR takes a function that I think it fits best here, considering 90% of the logic is just used directly by |
@stubailo do you need me to update anything here? 🙂 |
Hi, Is this still in the roadmap? It seems to be what I need to. Thanks ping @benjamn @freiksenet @mfix22 |
…ethods. May be useful for use with dataloaders or memoization. See ardatan#724
…ethods. May be useful for use with dataloaders or memoization. See ardatan#724
…ethods. May be useful for use with dataloaders or memoization. See ardatan#724
…ethods. May be useful for use with dataloaders or memoization. See ardatan#724
…ethods. May be useful for use with dataloaders or memoization. See ardatan#724
…ethods. May be useful for use with dataloaders or memoization. See ardatan#724
…ethods. May be useful for use with dataloaders or memoization. See ardatan#724
Closing in favor of alternative implementation within #1307. |
@freiksenet I just recreated the
createBatchOperation
function using the new transforms schema, andI am running into this error:"{ Error: Fields "bookingsByPropertyId" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional."
TODO: