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

Inability to Use transformSchema and Custom Directives in Apollo Gateway Configuration with @nestjs/graphql #3296

Open
2 of 4 tasks
ahmad-punch opened this issue Aug 16, 2024 · 2 comments

Comments

@ahmad-punch
Copy link

ahmad-punch commented Aug 16, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

The issue manifests when attempting to use the transformSchema and publicDirectiveTransformer in the Apollo Gateway configuration within a NestJS application using the code-first approach. Specifically, the transformSchema function never fires, and no console logs are generated, even when placed directly in the transformSchema function.

Additionally, the issue allows for any arbitrary property (like abc: true) to be added to the Gateway configuration without throwing any errors, indicating that the configuration is not being properly validated or processed by the @nestjs/graphql package.

Minimum reproduction code

https://github.com/ahmad-punch/nestjs-gateway-federation2-transformSchema-issue-reproduction-code.git

Steps to reproduce

Minimum Reproduction Code

You can reproduce this issue with the following code setup:

Approach:

  • GraphQL: Code-first
  • Schema Generation: Auto-generated using autoSchemaFile: { federation: 2 }
  • NestJS Modules: @nestjs/graphql, @apollo/gateway

GitHub Repository:
A minimal reproduction repository is available here:
https://github.com/ahmad-punch/nestjs-gateway-federation2-transformSchema-issue-reproduction-code.git

Steps to Reproduce

Generic Steps:

  1. Create a NestJS project with the @nestjs/graphql and @apollo/gateway packages.
  2. Set up the GraphQLModule with the Apollo Gateway Driver as shown in the provided app.module.ts.
  3. Attempt to use transformSchema or any other schema transformation functions.
  4. Observe that transformSchema is never called, and no logs from this function are visible.
  5. Also, add any arbitrary key (like abc: true) to the gateway configuration and observe that it does not throw an error or get processed.

Steps Using GitHub Repository:

  1. Clone the repository:

    git clone https://github.com/ahmad-punch/nestjs-gateway-federation2-transformSchema-issue-reproduction-code.git`
    
  2. Navigate to the platform-service folder, install dependencies, and start the service:

       cd /platform-service 
       npm install
       npm run dev  `
    
  3. Once the platform service is started, navigate to the gateway folder, install dependencies, and start the gateway service:

     cd ../gateway
     npm install
     npm run dev 
     `
    
  4. Open the GraphQL Playground for the gateway, and execute the following query:

       query {
       findAllTest {
       exampleField
           }
         } 
       `
  5. Observe the logs of the gateway server. You will notice that the gateway does not detect the directive, nor does it run any logs mentioned in the transformSchema function in the app.module.ts of the gateway. However, it should.

Expected behavior

  • The transformSchema function should be called, and logs should be visible to confirm that the schema is being transformed.
  • The configuration should be validated to prevent arbitrary keys from being added without causing an error.
  • The Gateway should be able to correctly handle and apply custom directives from subgraphs (like @public), allowing them to control behavior such as skipping authentication checks.

Package version

12.2.0

Graphql version

    "dependencies": {
                                 "@apollo/gateway": "^2.8.1",
                                 "@apollo/server": "^4.11.0",
                                 "@apollo/subgraph": "^2.8.1",
                                 "@nestjs/apollo": "^12.2.0",
                                 "@nestjs/common": "^10.0.0",
                                 "@nestjs/config": "^3.2.3",
                                 "@nestjs/core": "^10.0.0",
                                 "@nestjs/graphql": "^12.2.0",
                                 "@nestjs/microservices": "^10.3.10",
                                 "@nestjs/mongoose": "^10.0.10",
                                 "@nestjs/platform-express": "^10.0.0",
                                  "graphql": "^16.9.0",
                                  "jsonwebtoken": "^9.0.2",
                                  "mongoose": "^8.5.1",
                                  "reflect-metadata": "^0.2.0",
                                  "rxjs": "^7.8.1"
                           }

NestJS version

10.0.0

Node.js version

18.17.0

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

Why I'm Doing This

The main goal is to add a directive in the subgraph (e.g., @public) that will instruct the supergraph/gateway to leave certain queries public, effectively bypassing authentication for those queries. The gateway should respect this directive, allowing the subgraph to control which queries require authentication and which do not.

However, due to the issues outlined above, the intended behavior cannot be achieved. The transformSchema function is not being called, custom directives are not processed correctly, and the configuration is not being validated properly. This blocks the implementation of a flexible, directive-based authentication system in a federated GraphQL architecture.

@ahmad-punch
Copy link
Author

I was reading and I am not sure but this seems relevant:

#2059 (comment)

@jpiv
Copy link

jpiv commented Nov 14, 2024

+1 on this directive support is needed if you want to use a real router instead of Apollo Gateway

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants