@apollo/client scalability as a primary data layer

General
,
1

:wave: I’m writing to get feedback from other users of @apollo/client, especially in a React application, mostly using useQuery.

I’ve been able to build some amazing experiences because of the flexibility of useQuery with its cache-first approach. I am however getting to a point where scalability is a concern.

We’re using @apollo/client for everything on my e-commerce application. On the main screen, there are rows of Items, each of which has many components and variations. Users can page through rows of Items, so 100s can be loaded.

Each Item is a component with 30+ useQuery invocations. We fetch price, attributes, translated strings, and many other pieces.

This usage creates quite a few Long Tasks in the browser as we’re loading item cards, with cache access and broadcasts of new query results being the major bottleneck.

image
image1642×771 363 KB

In this image, the light blue color is all work within @apollo/client after our react app has hydrated.

My questions for the forum are:

  1. Is this happening to others?
  2. Are we misunderstanding how to use @apollo/client
  3. Are there techniques we can use to improve perf that keep the flexibility we’ve come to enjoy?

Thanks!

1 Like
2

Hello there!

Thanks for asking this question! It would be helpful if you could provide a reproduction with some sample code so we can better understand why a single item in a list is making 30 useQuery calls. If you follow this link you can open an issue in our Apollo Client project on Github. In the issue template markdown we provide instructions on how to produce a reproduction. using GitHub - apollographql/react-apollo-error-template: Apollo Client issue reproduction. and link to it here. If you prefer an in-browser way to create reproduction, try: apollo-client-error-template - CodeSandbox

3

Thanks @jpvajda , i posted an issue here.

1 Like
4

We appreciate that @dkempner! We can work off that issue an collaborate as needed soon. Thanks again. :pray: