avoiding bundling graphql.js

[Schniz]

Hey friends! Thanks for the amazing project.

Is there a way to make Urql slimmer by avoiding having the extra dependency of graphql.js by pushing all the GraphQL work possible by something like graphql-codegen? 🤔

[kitten]

Yes, and no. Let me elaborate. 😅

Is it easly possible to bundle nothing from graphql? Absolutely not. There are several things that you could alias away to get rid of them, sure, but ultimately there are some dependencies that are more or less important. But that's not a bad thing. Let me explain how this makes sense, what you can do, and what makes sense to do.

The dependencies in @urql/core you'll see are:

import { GraphQLError } from "graphql/error/GraphQLError.mjs";
import { parse } from "graphql/language/parser.mjs";
import { print } from "graphql/language/printer.mjs";
import { Kind } from "graphql/language/kinds.mjs";

Here we can see the entrypoints of what is used on a basic level. You can ignore Kind, it's just an object/enum of GraphQL types/kinds to stay longterm backward- and forward-compatible. GraphQLError here is nice for hydrating errors from the API to actual GraphQLErrors again, which is intuitive and very cheap, as it's a tiny module. And to quickly take another module away here print is comparatively small as it uses standard traversal logic and, well, string concatenation. It's a module that only supports printing the query DSL so pretty specialised (since it's counterpart is printSchema)

That brings us to parse. parse is comparatively cheap but not small. It pulls in several other modules that aren't otherwise used to execute on its parsing logic. Ultimately it pulls in two categories of things: lots of AST language classes that abstract the DSL, and parts of the parsing process like the lexer, parser, and some utilities.

If I'm not mistaken though the total impact of graphql here isn't as large as you'd expect. I don't want to post any numbers because I haven't updated them in a while, so more on that once I get to double-checking them.

What about Graphcache? This pulls in (additionally):

import { valueFromASTUntyped } from "graphql/utilities/valueFromASTUntyped.mjs";
import { isNullableType, isNonNullType, isListType, GraphQLObjectType, GraphQLInterfaceType, GraphQLUnionType } from "graphql/type/definition.mjs";
import { buildClientSchema } from "graphql/utilities/buildClientSchema.mjs";

The valueFromASTUntyped utility is negligible. The type definition types are already pulled in by parse and are completely ignorable too and small. buildClientSchema is larger, but honestly, we haven't seen much issue with that. Personally, it's on my list to look into, but I think the looks here were deceiving.

The large question you're asking is: How much of an impact does graphql have? An I'd say: It varies. We have to remember that graphql is a package that isn't just the number of all modules combined. In fact, we import specific modules to reduce the bundlesize impact since treeshaking doesn't otherwise always get it all. It is a package containing universal, client-side, and server-side utilities for GraphQL all in one.

The big one here is still parse. You can indeed precompile your queries. At that point for ease-of-use parse will still be imported by urql, since otherwise there'd be no way to ensure consistent parsing inside the core library. It's not like we can avoid that at all unfortunately. So what can you do? Create an alias if you have precompilation. If you consistently precompile DocumentNode then you can totally just alias this module away (although there's also a low size alternative I've worked on for production, which is graphql-parse on npm)

So, at this point, I could go on, but basically the impact is pretty overseeable. I'd love to get more accurate numbers behind this, but it's always a little elusive as there's been changes in graphql and changes in what you use matter too.

Anyway, the tl;dr is urql does a lot more than just send a string to an API endpoint. There's several small parts of graphql we use, parse being one that can indeed be aliased away in the presence of precompilation. But overall the impact is small and this isn't the first thing I'd look at when building an app.

[kitten]

Just checking in on the numbers, it looks like graphql, as it's used in a production build by urql without @urql/exchange-graphcache comes down to about 10kB gzip, which is an estimate and rounded. You can save about 5.4kB gzip if you were to eliminate graphql/language/parser.mjs by aliasing it away — possibly a little less.

The impact of @urql/exchange-graphcache is harder to estimate, but its own size is about 6.73kB, so subtracting that from what I'm seeing it pull in from graphql, I'd put it at about an additional 9-10kB gzip from graphql, possibly less.

So that does line up with some older numbers we had, which put it all at ~15kB for all urql packages, including Graphcache, and that doubling with graphql's files that are pulled in (again, only if @urql/exchange-graphcache is used). It's possible we'll be able to reduce the impact here by replacing graphql/utilities/buildClientSchema.mjs but overall it's inline with what I expected.

[kitten]

This thread actually prompted me to look into this again 😅 ❤️ The exact impact of @urql/exchange-graphcache's usage of buildClientSchema turns out to be about 5.83kB gzip and this is actually replaceable with a much lighter alternative implementation that's only then used for the purposes of Graphcache's schema awareness and nothing more. This results in savings of about -5.32kB gzip in an app that builds @urql/exchange-graphcache into its production bundle due to what's saved from graphql/utilities/buildClientSchema.mjs (and deps) vs the 0.51kB gzip it (currently) adds.

#1189

[kitten]

Actually it looks like about up to 9.61kB from graphql can at all be avoided, so the net impact will be up to -9.42kB gzip.

[Schniz]

Woah! thanks for the detailed answer 😲

I'm working on a widget that uses GraphQL to communicate to a server, and I'm trying to minimize my bundle size as much as possible, while still having a great developer experience. I think that urql sits in a very good place both in terms of being lean and being extremely fun to work with. I just didn't understand why graphql is being bundled.

Now I see that there are muuuuuch more things that urql is handling. I wonder if there is something to watch/read about how urql works behind the scenes. It would be awesome.

Anyway, really appreciate the detailed answer and working on this fantastic product. Any kB you shave off urql makes it even more lean which is awesome. I will follow the work on #1189, but stay with using urql without aliasing stuff 😅

Thanks 😄