GraphQL Mesh no longer compatible with Cloudflare Workers

[ARWhattam]

Issue workflow progress

Progress of the issue based on the Contributor Workflow

• [x] 1. The issue provides a reproduction available on Github, Stackblitz or CodeSandbox

Make sure to fork this template and run yarn generate in the terminal.

Please make sure Mesh package versions under package.json matches yours.

• [ ] 2. A failing test has been provided
• [ ] 3. A local solution has been provided
• [ ] 4. A pull request is pending review

---

Describe the bug

Since runtime v0.96 and graphql-jit was included we are no longer able to get GraphQL Mesh running on a Cloudflare Worker.

The first issue is caused by two new npm packages that both use the "util" package built into Node. These are fast-json-stringify and generate-function. This issue can be overcome by setting node_compat = true which uses polyfills. However this is something we wanted to avoid if possible. Is there a better workaround for this?

After enabling node_compat we can run GraphQL Mesh on a worker. However we then get the following error when sending a request:

{
  errors: [
    EvalError: Code generation from strings disallowed for this context
        at Function (<anonymous>)
        at build (file:///Users/alexander.whattam/shared-services/typescript-mesh_gateway_worker/.wrangler/tmp/dev-ZVaGaC/index.js:34002:23)
        at compileQuery3 (file:///Users/alexander.whattam/shared-services/typescript-mesh_gateway_worker/.wrangler/tmp/dev-ZVaGaC/index.js:38413:57)
        at getCacheEntry (file:///Users/alexander.whattam/shared-services/typescript-mesh_gateway_worker/.wrangler/tmp/dev-ZVaGaC/index.js:83966:69)
        at jitExecutor (file:///Users/alexander.whattam/shared-services/typescript-mesh_gateway_worker/.wrangler/tmp/dev-ZVaGaC/index.js:83991:24)
        at file:///Users/alexander.whattam/shared-services/typescript-mesh_gateway_worker/.wrangler/tmp/dev-ZVaGaC/index.js:83229:52
        at file:///Users/alexander.whattam/shared-services/typescript-mesh_gateway_worker/.wrangler/tmp/dev-ZVaGaC/index.js:80182:22
        at async YogaServer.getResultForParams (file:///Users/alexander.whattam/shared-services/typescript-mesh_gateway_worker/.wrangler/tmp/dev-ZVaGaC/index.js:82910:18)
        at async handle (file:///Users/alexander.whattam/shared-services/typescript-mesh_gateway_worker/.wrangler/tmp/dev-ZVaGaC/index.js:82964:20)
        at async Object.fetch (file:///Users/alexander.whattam/shared-services/typescript-mesh_gateway_worker/.wrangler/tmp/dev-ZVaGaC/index.js:86737:28)
  ]
}

This seems to be caused by graphql-jit code generation. Is there a way we could switch back to graphql-js? Or is there a different workaround that could fix this, like running the code generation at compile time?

To Reproduce Steps to reproduce the behavior:

Try to run GraphQL Mesh in a Cloudflare Worker as described above.

Expected behavior

Do not see errors above.

Environment:

• OS: Mac
• @graphql-mesh/runtime: 0.97.0 (issue since 0.96)
• NodeJS: 18

Additional context

[andyevans2000]

Is there likely to be a fix / workaround for this?

[Urigo]

Thank you @ARWhattam and @andyevans2000 for the report!

Sorry but I'm not adding a lot here but just labeling it according to our new Contribution Guide and issue flow.

It seems already got into stage 0.

Now in order to advance to stage 1 we'll need a simple reproduction, maybe in code-sandbox?

Later to progress to stage 2, a failing test would be needed, would be great if someone could help progress the issues through the stages.

Thank you and sorry that this comment is not a complete solution (yet).

[ARWhattam]

Here is a reproduction in CodeSandbox

Just send any request and it should show the error. Is that enough for stage 2? As this is environment-specific I don't think having an automated test would be that beneficial. One would be possible but it would require setting up a new wrangler dev environment each time the tests are run which seems a little overkill.

EDIT: Updated link as previous CodeSandbox lost changes.

[ARWhattam]

@ardatan Have you had a chance to look at this one? We have a few ideas for potential fixes and happy to discuss which ones you would to be happy to go into the code or may be feasible. I think we can either:

• Add a dummy transform to our .meshrc.yaml which will bypass graphql-jit
• Add a flag to always use graphql-js if eval() is not allowed on your environment
• Compile a list of queries at build time, if a custom query is sent this would use graphql-js - not sure how feasible this is