contra/graphql-helix

Compatability with other libraries on deno

Opened this issue · 0 comments

hayes commented

Hey! I saw that helix has some support for running on deno, and was inspired to make one of my projects (GiraphQL) work on deno as well.

GiraphQL is a graphql schema builder that doesn't handle any of the server logic, making it an ideal pairing with helix. I couldn't find much info on how you recommend setting up helix on deno, but after some tinkering got something that works.

A couple issues I ran into:

  • It looks like something in render-graphiql.ts causes deno's parser to choke and crash the process. I worked around this by just importing the other files directly and using something else to load graphql playground.
  • the way the graphql library is written makes it impossible to use multiple copies of graphql together. This isn't a huge issue in node because you can use things like yarn resolutions to ensure only one version of graphql exists in you node_modules directory. This can be worked around in deno using import-maps. The down side of this is that every time you update helix you need to dig through the source to find exactly which version (and url) is being used to load graphql, and then update your import-map to match.

I was curious if you had run into any of these issues or had thoughts on best practices to recomend to users of our libraries.

One idea I had that may make sense is to always use the same url/version of graphql (something like https://cdn.skypack.dev/graphql?dts), and strongly encourage users to use import maps that replace this version. By using a non-versioned url, new users will pick up the latest version by default, and user upgrading libraries don't need to worry as much about check the specific versions being imported by the new version.

I put together some docs with an working example of GiraphQL and helix here https://giraphql.com/guide/deno if you're curious.