Skip to content
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

Filtering a source schema also filters that schema's SDK #3367

Open
leemhenson opened this issue Dec 21, 2021 · 4 comments
Open

Filtering a source schema also filters that schema's SDK #3367

leemhenson opened this issue Dec 21, 2021 · 4 comments
Labels
stage/4-pull-request A pull request has been opened that aims to solve the issue

Comments

@leemhenson
Copy link

Describe the bug
I want to filter a source schema so that some of it's members don't appear in my stitched schema. I think there are two ways of doing that:

  1. applying the filter transform on the source
  2. applying a root filter

When I try option 1, it works in that my stitched schema doesn't show those members. However, if I attempt to use the source's sdk from a custom resolver's context, I find those members are also filtered out and I can't query it.

When I try option 2, the Typescript declarations file is not emitted to .mesh/index.d.ts. This obviously kills all the typescript code in my project that depends on those types.

To Reproduce
Steps to reproduce the behavior:

Sandbox for option 1: https://codesandbox.io/s/hungry-montalcini-57ge6?file=/resolver.ts

You can see there are no members available on the AuthorService.Query type. If you comment out the transforms in the meshrc and rerun yarn build, the type is then populated.

Sandbox for option 2: https://codesandbox.io/s/condescending-swanson-9n0ux?file=/.mesh/schema.graphql

If you run yarn build you will see that no typescript declarations are emitted into the .mesh directory.

Expected behavior

I can see an argument for saying that transforms applied to the source schema should be reflected in that source schema's context sdk. If that's the case, root transforms must correctly emit the typescript declarations. Alternatively, it seems equally valid to say that the context sdk should be a true reflection of the upstream schema, and source transforms should only apply during the stitching.

Environment:

  • OS: MacOS 11.6
  • "@graphql-mesh/cli": "^0.44.4"
  • "@graphql-mesh/graphql": "^0.20.9"
  • "@graphql-mesh/transform-filter-schema": "^0.14.5"
  • NodeJS: 14
@leemhenson
Copy link
Author

Spent a bit of time debugging why using a root filter transform would break typescript declaration emit during mesh build. My issue is due to this:

  • source Author schema has Query { author: SomeType, other fields... }
  • I want to omit author in my schema, but leave it in the source schema so it's generated SDK can be used to query it
  • I use the root filter transform: Query.!author
  • The intermediate typescript code that is passed to Typescript for compilation contains the following definition:
export type QueryAuthorServiceSdk = {
  author: InContextSdkMethod<Query['author'], QueryauthorArgs, MeshContext>
  // ... other definitions
};

The problem is that the Query type referenced here does not have an author property on it, as it was filtered out. The Query type here should be the Query type for the Author schema, not the Query type for the stitched schema. However, no such type is in scope at this point.

This all happens during generateTypesForApi and buildSignatureBasedOnRootFields, if that helps.

If you've got any guidance on where you would see this going, I'm all ears!

@leemhenson
Copy link
Author

I've added a draft PR with a naive implementation that works for me. ^

@ardatan
Copy link
Owner

ardatan commented Jan 4, 2022

Thank you @leemhenson ! I'll take a look soon!

@ardatan ardatan added the stage/4-pull-request A pull request has been opened that aims to solve the issue label Jan 4, 2022
@leemhenson
Copy link
Author

A bit of extra information - the patch I've got doesn't work when the name of a field has been renamed. I'm expecting the pascal-cased version of the field name to match the name of the Args type in the subschema, but after the rename of course it won't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stage/4-pull-request A pull request has been opened that aims to solve the issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants