Graphql-tag: Webpack loader: Large queries make large webpack bundles

[mohsen1]

Using graphql-tag/loader with large queries can lead to generating lots of JavaScript in form of GraphQL Document AST objects. I recently moved an app from using gql\ query {}to importing queries from.graphqlfiles leveraging the'graphql-tag/loader` Webpack loader and saw an increase in our bundle size.

Using the gql\ query {}` has its own limitations(https://github.com/apollographql/apollo-cli/issues/182) but shipping queries as JS strings is more efficient.

This is an open discussion on how to mitigate this issue. Can it be a "minify" option to convert back the document to string using the printer? is it always more efficient to do that?

Thoughts?

[bregenspan]

The query trees gzip pretty well, but I agree it'd be very nice to get things further compressed to reduce parse time (in the project I'm working on, queries represent 5% of the Webpack bundle and probably do non-trivially contribute to parse time on slow devices). One other thought besides transforming the query string at runtime is having a loader that delivers more or less the same response as it does now, but optimized for minification by assigning all strings that are likely to be repeated (e.g. properties of each of the nodes like "kind", "arguments") to constants and referencing those constants instead of returning literals. This could allow for tools like Uglify to return a much smaller response with mangled variable names (might or might not be a net improvement taking parse and execution time into account...).

It might also be possible to strip out default values (e.g. things like alias:null, arguments:[], directives:[], selectionSet:null).

[bxt]

I think Apollo needs the queries at runtime at some place, for caching etc. But what I also thought of is using persisted queries and only sending the ID of the query to the browser initially, the browser can then send this ID only to the server, without loading the full AST yet. If the server does not know the ID yet or the results come back, the browser could then load the full AST from another (later) bundle file and give it to Apollo.