Q. Can we preload multiple queries In RSC using <PreloadQuery>

[swaroopb2001]

We have next.js web app using Apollo to fetch data and have an use case to prelaod data in our RSC for multiple queries . I see that the documentation has a section on https://github.com/apollographql/apollo-client-integrations/tree/main/packages/nextjs#preloading-data-in-rsc-for-usage-in-client-components .

According to this it takes a single query document . Is there any way we can pass multiple queries as args ?

<PreloadQuery
  query={QUERY}
  variables={{
    foo: 1,
  }}
>
  <Suspense fallback={<>loading</>}>
    <ClientChild />
  </Suspense>
</PreloadQuery>

[phryneas]

Not directly, as it's not encouraged.

Generally we recommend to use fragment composition and only have a single query per page.

That said, it's also fine to have a small number of queries (although usually I'd expect those to be preloaded for different subtrees). If you really need to, you can nest multiple <PreloadQuery components.

[swaroopb2001]

Thanks for the quick response ! 😃 . I was kinda deciding whether to nest multiple PreloadQuery or call these queries in a single document

In our setup we’re dealing with a microservice-style architecture, we need data coming from different backend domains and we have 5-6 queries with different resolvers. What we have now

'use server';

import React from 'react';
import { execParallelQueriesTyped } from '@/lib/graphql-helpers';
import { getDateRange } from '@/lib/date-utils';

import {
  QueryOneDocument,
  QueryTwoDocument,
  QueryThreeDocument,
  QueryFourDocument,
  QueryFiveDocument,
  QuerySixDocument,
} from '@/graphql/types';

// --- server component used in the page slot ---
export default async function SlotContainer({ userUuid }: { userUuid: string }) {
  const [start, end] = getDateRange();

  const commonVars = {
    memberUuid: userUuid,
    startDate: start.toUTC().toISO(),
    endDate: end.toUTC().toISO(),
  };

  const [
    resultOne,
    resultTwo,
    resultThree,
    resultFour,
    resultFive,
    resultSix,
  ] = await execParallelQueriesTyped([
    { document: QueryOneDocument, variables: commonVars },
    { document: QueryTwoDocument, variables: commonVars },
    {
      document: QueryThreeDocument,
      variables: {
        userUuid: commonVars.memberUuid,
        startAt: new Date(commonVars.startDate),
        endAt: new Date(commonVars.endDate),
      },
    },
    { document: QueryFourDocument, variables: commonVars },
    { document: QueryFiveDocument, variables: commonVars },
    { document: QuerySixDocument, variables: { userUuid } },
  ]);

  return (
    <SlotContent
      data={{
        resultOne,
        resultTwo,
        resultThree,
        resultFour,
        resultFive,
        resultSix,
      }}
    />
  );
}

We were planning to move to preload to populate client cache since since we have different views and date ranges and certain operations in client side which fetches these queries again with different args (other then default args fetched in server ) and mutates some of these current data as well.

Just to confirm my understanding — when you say “fragment composition is encouraged”, the idea is that even if a page needs data from multiple resolvers, the recommendation is to combine everything into a single query document and then organize each resolver’s field selection into modular fragments.

# fragments.gql
fragment DataOne on TypeOne {
  fieldA
  fieldB
}

fragment DataTwo on TypeTwo {
  fieldC
  fieldD
}

fragment DataThree on TypeThree {
  fieldE
}

fragment DataFour on TypeFour {
  fieldF
  fieldG
}

fragment DataFive on TypeFive {
  fieldH
}

fragment DataSix on TypeSix {
  fieldI
}

And then compose them into one query:

# PageData.gql
query PageData($id: ID!) {
  resolverOne(id: $id) {
    ...DataOne
  }
  resolverTwo(id: $id) {
    ...DataTwo
  }
  resolverThree(id: $id) {
    ...DataThree
  }
  resolverFour(id: $id) {
    ...DataFour
  }
  resolverFive(id: $id) {
    ...DataFive
  }
  resolverSix(id: $id) {
    ...DataSix
  }
}

Then in RSC

<PreloadQuery
  query={PageData}
  variables={{ id }}
>
  <Suspense fallback={<>loading…</>}>
    <ClientChild />
  </Suspense>
</PreloadQuery>

Did I get it right that this is the encouraged pattern over nesting multiple <PreloadQuery> components (even if we have several resolvers in play)?

Also another minor follow up on how error handling would work here ? Setting error policy to all should be enough to ensure one failure doesn't affect the other ? My main concern is it shouldn't throw any error to be caught by an error boundary and should just populate the errors key .

[phryneas]

I'm sorry, I think I didn't link deep enough into those docs - the important recommendation here is the part in Colocating Fragments.

The idea is that your frontend should generally never think in "resolvers", but in "data needs". Each of your components should, (assuming it needs some data), define a fragment that describes what exactly it needs - and a parent component would then combine the fragments of all child components into it's own fragment again - until you reach the "top" component, which would issue a query.
The components themselves would use useSuspenseFragment to access their data.

This avoids multiple network requests, and if combined with Data Masking not only prevents a component from accidentally accessing data it doesn't declare as a data need itself - it would also prevent rerenders from data updates coming in unless a "needed" field really updates.

Also another minor follow up on how error handling would work here ? Setting error policy to all should be enough to ensure one failure doesn't affect the other ? My main concern is it shouldn't throw any error to be caught by an error boundary and should just populate the errors key .

I would really go for error boundaries. If you get to the point where you want to show two different errors in two different places, that would probably really be the point where you'd want to split up a query into two, but generally I'd really recommend against handling errors on a component level. Separate "this component needs this data" from "if an error happens in this part of the app, I want to display an error".

[swaroopb2001]

Oh got it. Thanks for the the response !

[akin-fagbohun]

Oh got it. Thanks for the the response !

@swaroopb2001 - I wonder, what did you come up with in the end?