Urql: Bundle size impact of the graphql package

[helloguille]

After integrating URL with SSR, I found out that urql adds 600kb via the "graphql" dependency. (urql is very tiny in comparison)

Is there any simple way to reduce the total bundle size added by graphql?

[kitten]

So you should only see a _maximum_ impact of about 41kB min+gzip, which obviously still isn't great, but a lot of the graphql library should be tree-shaken away actually, since we're only using parts of it.

This isn't great and in fact @mxstbr suggested that we slightly change how we accept GraphQL document strings so that it becomes possible to leave out the entire dependency on graphql, so this is definitely on our radar :+1:

[helloguille]

Thanks for such a quick response. I love the library.

I consider 41kb to be alright, smaller would be even great but, I assume then in my case tree-shaking is not working in my webpack. So I'll look for a solution on that side.

[helloguille]

Indeed, was a tree-shaking problem. Thanks for the hint.

[JoviDeCroock]

@kitten is that proposition documented somewhere? I could try and tackle it.

[kitten]

@JoviDeCroock I think it'll involve breaking changes, so I'll discuss it with @andyrichardson and maybe we'll have to park this until v2

[oreqizer]

would love to see this happen — tree-shaken graphql is 1.5x the size of the whole urql

[chrstntdd]

I know this is a closed issue, but I was curious about trying to cut out the graphql dependency as well. Has there been any progress made or further discussion? If so, where? If not, how can people help get started?

[JoviDeCroock]

Hey @chrstntdd

So I looked through our codebase and the only two things we use from the graphql package are parse and print (the other things are types). These are also used in the graphql-tag package you would be forced to use if we'd remove these two.

So what do we use these for you might ask? Well parse is used to transform our query into a Document compatible when we sent it.
In case you already sent us a compiled gql query we need to prettyprint this first to generate our unique key, https://github.com/FormidableLabs/urql/blob/master/src/utils/request.ts#L28

This key is one of the driving factors of the document-cache. We have already deleted some of the things we used from graphql but I think it'll be hard to bypass these last two.

[marcusdarmstrong]

We’d also be interested in this—as far as the current Urql usage goes, we use a custom GraphQL loader to generate the keys at compile time to avoid that runtime dependency.

[oreqizer]

I would prefer having to use graphql-tag for static optimisation and reducing bundle size any day — small bundle size impact is one of the biggest benefits of this package, IMO everybody would enjoy nuking ~9kb more

[JoviDeCroock]

@oreqizer if you use graphql-tag you will pull in the same dependencies this won't make a difference, only if you'd make babel pre-compile your queries.

The graphql dependency accounts for < 1kb as well in the case of urql standalone