We are using graphql in one of our applications. We have a question regarding the performance of graphql with webpack. We are able to load graphql queries using ‘gql’ tag from ‘graphql-tag’ and also using separate ‘.graphql’ files and compile them using webpack ‘graphql-tag/loader’. We would like to know which one is the preferred approach and why?
Depends on your use case.
Check your build and caching results, and I’d say tweak depending on your wants & needs. I use the graphql tag approach for my applications right now, so it’s been a while but I’m pretty sure I don’t even use a special loader.
If I wanted to get very picky about the results, I would look into the following:
- Are the results baked into the JS as strings, or can you get them to output without loading them into the JS directly?
- If you bake them into the JS, can you split them out into their appropriate chunks?
- How much syntactic sugar do you want? Some of the tools around
gql-tagallow you to compose your queries in a module-like way, similar toJSS. - If you manage to output the graphql in the build as
.graphqlfiles, how do you want caching to work?- For example, when I do my server-side schemas I use
@graphql-tools/loadto load static.gqlfiles, so my schemas aren’t baked into the JS. You could theoretically do something similar by making your graphql filesassets. Which, if you can load them, might give you better caching because some queries are completely static, and only the variables change.
- For example, when I do my server-side schemas I use