Bundle size is very big

I find that Apollos bundle size is quite big, to the point where I’m thinking about moving away from it. Maybe there are things to do about that?

As of right now, Apollo outweighs both React and Material-UI by quite a bit and is therefore my largest dependency. The biggest modules caused by my Apollo usage are:

Total parsed: 137.26 kB
Total GZipped: 39.12 kB

Parsed Sizs:
  apollo-client 38.76 kB
  apollo-cache-inmemory 26.18 kB
  react-apollo 22.48 kB
  subscriptions-transport-ws 12.54 kB
  graphql 10.12 kB
  apollo-utilities 10.07 kB
  zen-observable 6.56 kB
  apollo-link-http 4.94 kB
  apollo-link 2.92 kB
  eventemitter3 2.69 kB

GZipped Sizes:
  apollo-client 10.11 kB
  apollo-cache-inmemory 7.24 kB
  react-apollo 5.88 kB
  subscriptions-transport-ws 3.81 kB
  graphql 2.95 kB
  apollo-utilities 2.93 kB
  apollo-link-http 2.07 kB
  zen-observable 2 kB
  apollo-link 1.13 kB
  eventemitter3 1 kB

I open this issue as a discussion starter

[jaydenseric]

@Pajn After using Apollo Client and react-apollo for long time I took a step back and thought critically about how a GraphQL client could be architected from the ground up for efficiency; the result being graphql-react. It’s bundle-impact is ~2.5kb (tested here), compared to Apollo’s ~40kb.

It’s a lot easier to configure and use (one package, less config, uploads work out of the box, etc.), has a way smaller surface area for bugs (zero known ATM), and can even do some things that Apollo can’t that matter to me (i.e. SSR errors, easily refresh cache post mutations without also blowing away the mutation payload, etc.) trading off a few things that I don’t really need, like subscriptions, which could be implemented in the future anyway.

enamor.app uses graphql-react and Next.js. The JS for fresh app/page load is only ~100kb (including Google Analytics), with subsequent routes around ~5kb each:

It might be up your alley.

While some of Apollo’s ~40kb bundle impact could be reduced to perhaps ~20kb with polish, I doubt sub 10kb is possible without rethinking the way it works (i.e. scrapping normalized cache, links, gql tagged template strings, graphql dependency, etc.).

[hwillson]

While some of Apollo’s ~40kb bundle impact could be reduced to perhaps ~20kb with polish, I doubt sub 10kb is possible without rethinking the way it works (i.e. scrapping normalized cache, links, gql tagged template strings, graphql dependency, etc.).

Challenge accepted @jaydenseric 🙂. Seriously though, bundle size reduction is one of the items that’s next up on our todo list.