Updating Apollo with Nextjs because of getStaticProps and getServerSideProps

[danboyle8637]

I was reading the example in the Next repo:
https://github.com/zeit/next.js/blob/canary/examples/with-apollo/lib/apollo.js

And in this file (starting at line 107) getInitialProps is still used for ssr... should or could that be changed to getServerSideProps?

And what if we want to use getStaticProps with a query?

Or since it looks like this file is returning an object with the apolloClient on it... would we just use the client in getStaticProps and run the query there?

[nickluger]

On SSG-pages you can do something like this.

1. You provide a standalone Apollo client that you only use at build time for SSG or maybe for some SSR pages you have, too. If you do SSR you can pass cookies or auth tokens. For SSG only, you don’t need them as they’re always public pages.

export async function getStandaloneApolloClient() {
  const { ApolloClient, InMemoryCache, HttpLink } = await import(
    "@apollo/client"
  );
  return new ApolloClient({
    link: new HttpLink({
      uri: "https://..../graphql"
      fetch
    }),
    cache: new InMemoryCache()
  });
}

2. You use it in getStaticProps to fetch your stuff and extract the cache and pass it as props.

export const getStaticProps = async ({ params }) => {
  const client = await getStandaloneApolloClient();
 await client.query({
    query: getPost,
    variables: { input: { slug: params?.slug } }
  });
  return {
    props: {
      apolloStaticCache: client.cache.extract()
    }
  };
};

3. Then you export the page with a HOC:

export default withApollo(Page);

while the HOC contains something like:

let globalApolloClient: ApolloClient;

function initApolloClient(initialState) {
  if (!globalApolloClient) {
    globalApolloClient = new ApolloClient({
      link: from(
        new HttpLink({
          uri: ".../graphql",
          fetch
        })
      ]),
      cache: new InMemoryCache().restore(initialState || {})
    });
  }
  // client side page transition to an SSG page => update Apollo cache
  else if (initialState) {
    globalApolloClient.cache.restore({
      ...globalApolloClient.cache.extract(),
      ...initialState
    });
  }
  return globalApolloClient;
}

export function withApollo(PageComponent) {
  const WithApollo = ({
    apolloStaticCache,
    ...pageProps
  }) => {
// HERE WE USE THE PASSED CACHE
    const client = initApolloClient(apolloStaticCache);
// and here we have the initialized client 🙂
    return (
      <ApolloProvider client={client}>
        <PageComponent {...pageProps} />
      </ApolloProvider>
    );
  };
// if you also use it for SSR
  if (PageComponent.getInitialProps) {
    WithApollo.getInitialProps = async () => {
      // Run wrapped getInitialProps methods
      let pageProps = {};
      if (PageComponent.getInitialProps) {
        pageProps = await PageComponent.getInitialProps(ctx);
      }
      return pageProps;
    };
  }

  // Set the correct displayName in development
  if (process.env.NODE_ENV !== "production") {
    const displayName =
      PageComponent.displayName || PageComponent.name || "Component";

    WithApollo.displayName = `withApollo(${displayName})`;
  }
  return WithApollo;
}

[Vadorequest]

Here is my own implementation:

import { InMemoryCache, NormalizedCacheObject } from 'apollo-cache-inmemory';
import { ApolloClient } from 'apollo-client';
import { createHttpLink } from 'apollo-link-http';
import fetch from 'isomorphic-unfetch';

const link = createHttpLink({
  fetch, // Switches between unfetch & node-fetch for client & server.
  uri: process.env.GRAPHQL_API_ENDPOINT,

  // Headers applied here will be applied for all requests
  // See the use of the "options" when running a graphQL query to specify options per-request at https://www.apollographql.com/docs/react/api/react-hooks/#options
  headers: {
    'gcms-locale-no-default': false,
    'authorization': `Bearer ${process.env.GRAPHQL_API_KEY}`,
  },
  credentials: 'same-origin', // XXX See https://www.apollographql.com/docs/react/recipes/authentication#cookie
});

export const getStandaloneApolloClient = (initialState = {}): ApolloClient<NormalizedCacheObject> => {
  return new ApolloClient({
    link: link,

    // XXX Very important to provide the initialState, otherwise the client will replay the query upon loading,
    //  which is useless as the data were already fetched by the server (SSR)
    cache: new InMemoryCache().restore(initialState || {}), // Rehydrate the cache using the initial data passed from the server
  });
};

---

HOC withUniversalGraphQLDataLoader:

import { getDataFromTree } from '@apollo/react-ssr';
import { NormalizedCacheObject } from 'apollo-cache-inmemory';
import withApollo, { InitApolloOptions } from 'next-with-apollo';
import { getStandaloneApolloClient } from '../utils/graphql';

/**
 * Export a HOC from next-with-apollo
 *
 * Universal, works both on client and server sides
 * Doesn't fetch any data by itself, but provides a client that allows to do it in children components
 *
 * @see https://www.npmjs.com/package/next-with-apollo
 */
export default withApollo(
  ({ initialState }: InitApolloOptions<NormalizedCacheObject>) =>
    getStandaloneApolloClient(initialState), {
    getDataFromTree,
  },
);

---

_app doesn't defined getInitialProps, but it does define a render method as follow:

  render(): JSX.Element {
    const { Component, pageProps, apollo, err }: AppRenderProps = this.props;
    console.log('_app.render.pageProps', pageProps);

    if (pageProps.isReadyToRender || pageProps.isSSRReadyToRender || pageProps.statusCode === 404) {
      console.log('_app.render - App is ready, rendering...');
      return (
        <ApolloProvider client={apollo}>
          <Component
            {...pageProps}
            error={err}
            apollo={apollo}
          />
        </ApolloProvider>
      );
    } else {
      console.log('_app.render - App is not ready yet, waiting for isReadyToRender');
      return null;
    }
  }

And the _app is using the Apollo HOC:

// Wraps all components in the tree with the data provider
export default withUniversalGraphQLDataLoader(NRNApp);

See https://github.com/UnlyEd/next-right-now/pull/42/files#diff-76ad791c100f00f39c533e71f055643cR350

---

Usage:

export const getCommonStaticProps: GetStaticProps<StaticProps, StaticParams> = async (props: StaticPropsInput): Promise<StaticPropsOutput> => {
  const customerRef: string = process.env.CUSTOMER_REF;
  const locale: string = props?.params?.locale;
  const lang: string = locale.split('-')?.[0];
  const bestCountryCodes: string[] = [lang, resolveFallbackLanguage(lang)];
  const gcmsLocales: string = prepareGraphCMSLocaleHeader(bestCountryCodes);
  const defaultLocales: I18nextResources = await fetchTranslations(lang); // Pre-fetches translations from Locize API
  const apolloClient = getStandaloneApolloClient();
  const variables = {
    customerRef,
  };
  const queryOptions = {
    displayName: 'LAYOUT_QUERY',
    query: LAYOUT_QUERY,
    variables,
    context: {
      headers: {
        'gcms-locale': gcmsLocales,
      },
    },
  };

  const {
    data,
    errors,
    loading,
    networkStatus,
    stale,
  }: ApolloQueryResult<{
    customer: Customer;
  }> = await apolloClient.query(queryOptions);

  if (errors) {
    console.error(errors);
    throw new Error('Errors were detected in GraphQL query.');
  }

  const {
    customer,
  } = data || {}; // XXX Use empty object as fallback, to avoid app crash when destructuring, if no data is returned

  return {
    props: {
      customer,
      lang,
      locale,
      customerRef,
      bestCountryCodes,
      gcmsLocales,
      defaultLocales,
      apolloStaticCache: apolloClient.cache.extract(),
      isStaticRendering: true,
      isReadyToRender: true,
    },
    // unstable_revalidate: false,
  };
};

See UnlyEd/next-right-now#42 and more specifically UnlyEd/next-right-now@d6533c4

[dhazeley]

Using these methods are you able to persist the apollo InMemoryCache across client side page routes?

[Vadorequest]

I'm not sure, take a look at the PR above. I don't do that so I haven't tested it.

Demo at https://v1-hyb-mst-aptd-gcms-lcz-sty.now.sh/

[Vadorequest]

@dhazeley Yes it does, because the apolloState is passed through pages, and the ApolloClient gets initialised with it when available.

[sudomf]

Why using await import? I've never seen that before.

It's a dynamic import. Whit dynamic imports you can load modules on-demand, so you can just load this module when you need it. https://javascript.info/modules-dynamic-imports

[lfades]

Apollo examples have been updated with a new implementation that can be used with getStaticProps and getServerSideProps, go to the with-apollo example 👍

[dminkovsky]

I can't find an example of getServerSideProps in this example. And I'm wondering... how do you update the client cache with results from getServerSideProps after the first server render?

[alex-r89]

The example uses getStaticProps in the index.js page, here, but I believe you can just replace it with getServerSideProps if you wanted to use SSR rather than SSG.

I am finding though that using the with-apollo example does not work with my application, which uses an apollo express server on a Digital Ocean instance. The build fails with getStaticProps, returningError: Network error: Unexpected token < in JSON at position 0, and the page returns a 500 error with getServerSideProps. It works perfectly on Localhost using either of those methods, and perfectly when using CSR (IE not using a getStaticProps or getServerSideProps). I'm currently in the process of trying to work out why this is.

[FahmyChaabane]

The example uses getStaticProps in the index.js page, here, but I believe you can just replace it with getServerSideProps if you wanted to use SSR rather than SSG.

I am finding though that using the with-apollo example does not work with my application, which uses an apollo express server on a Digital Ocean instance. The build fails with getStaticProps, returningError: Network error: Unexpected token < in JSON at position 0, and the page returns a 500 error with getServerSideProps. It works perfectly on Localhost using either of those methods, and perfectly when using CSR (IE not using a getStaticProps or getServerSideProps). I'm currently in the process of trying to work out why this is.

@alex-r89 , How did you manage to fix this issue ?

[pix2D]

@lfades I see getDataFromTree is gone from the new example. I'm not sure of the internals of Apollo and how/why this was needed before and it isn't needed now, maybe you could clarify when you have a moment?

[adamayres]

Note that getInitialProps is not deprecated and you can still use that approach with getDataFromTree using AppTree there. We didn't include AppTree in getStaticProps / getServerSideProps initially as it causes issues in many cases. I assume you have not looked at it's implementation, you can read more about it here: #10946 (reply in thread)

@timneutkens thank you for the clarification. I had not read that thread and it clarifies things for me. I also went back and re-read this useful thread on the difference between getInitialProps and getServerSideProps.

If getInitialProps/AppTree and getDataFromTree will continue to be supported then it does not impact how we went about solving our specific use case nor does it mean there will be any issues for us to upgrade to future versions of Next/Apollo.

I'm willing to considering introducing AppTree for getStaticProps / getServerSideProps, however I don't think this will solve your case given that on navigation it will fetch the json for getStaticProps/getServerSideProps and you'd have to re-initialize the Apollo store on every route navigation 🤔

After reading the thread you linked I can see why this is a complicated issue. I imagine since getInitialProps runs on the client during route changes that it can use the same Apollo connection and cache instance and it just updates the existing store - this provides some benefits for preventing some calls that will just be a cache hit, such as getting auth user data or other data that might be shared across routes/pages. I am curious how this would be handled with using something like getServerSideProps? Is there someway to prevent common data that has already been fetched and cached once from being refetched during a route change?

Another side effect of using getInitialProps and allowing individual components to make data calls is during routing individual components that have faster data calls can begin to render sooner and other slower loading components can show a loading indicator/skeleton.

AppTree was excluded from the new data fetching methods also to prepare for some changes in React that I can't share details about yet. So it's likely to break in the future if we introduce it. Potentially we could call it something like unstable_AppTree or similar though

I am no longer sure I am advocating specifically for AppTree to be available in these new data fetching methods. I am however curious to learn more about the changes in React as well as other ways in which we might solve allowing the data calls to be co-located with their components.

[alex-r89]

Im really struggling to get getStaticProps or getServerSideProps working. I have implemented the front end in the exact same way as the current with-apollo NextJS example, but get Network error: Unexpected token < in JSON at position 0 at build time when using getStaticProps, and a successful build but 500 error page when using getServerSideProps.

I understand that this is due to HTML being returned (and not JSON) but I don't really know what I can do to fix this. The request never makes it to my backend server (which is hosted on Digital Ocean) so I assume this is some issue directly related to my Apollo Client?

[Vadorequest]

@alex-r89 Sounds like you've hit a 404/500 page, look at the html page generated that's returned instead of the expected JSON.

[alex-r89]

@Vadorequest yes indeed, I can see the HTML if i console log the error. What I dont understand is A) why this is returning a 404/500 and B) how I handle this.
As I said, i've taken the with-apollo example as it is so assume this doesnt handle errors correctly/at all.

I also don't understand why im getting a 404/500 (I think its a 500, not 404) in the first place because if I run this query on the client it works perfectly. I dont see how getStaticProps or getServerSideProps results in these errors.

My only guess is that it's something to do with SSL/cors on my apollo-express backend.

[Oikio]

Old way is still working fine and I hope we will get native support for Suspense in SSR for React and Apollo soon. I suppose it should resolve issues above on libraries level.

Nevertheless I would say all the frustration above is underrated. Current example does not reflect usecase of any meaningful app and it would lead people away from using Next.js if they would see it. Not being able to use Apollo hooks/components and defining query on page level will not work for real app. I wouldn't use Next.js myself if had seen this example instead of previous one.

upd: I have only found this discussion by occasion while was reviewing our implementation and found out that example has changed completely in last months.

[danboyle8637]

@johny Sorry I am new to using GraphQL in an app and I have yet to build my client app yet... but I was looking at the example. In the PostList component... is useQuery querying the in memory store and not making an actual network request because that was done at the page level with getStaticProps?

[johny]

I think this is how it works if I understand it correctly.
The getStaticProps executes queries which populates apollo in-memory cache, so later during the render time the same queries can be resolved from Apollo cache.

Btw, I've also ran into into regression bug in Apollo 3.0 where it was not working correctly - apollographql/apollo-client#6422

[JClackett]

@lfades I switched to the new with-apollo example and it seems to work quite nice - something I noticed though: is that when navigating to a SSG page, it runs the getStaticProps function (as expected), it then extracts the cached data and that is passed into the useApollo / initialise apollo hook (as expected) but im running into a flashing ui problem.

My example is that I have some posts that are generated with getStaticProps, but also a navbar with user links (log in/profile), so I have a useMeQuery() in the nav, this obviously can't be generated at build time so the data is fetched on the client, this is all good. on the initial load the posts are pre-rendered and the nav gets the user data and shows the appropriate links (all good so far). the problem then comes when navigating to another SSG page. it then re-runs the me query even though its already been cached causing the nav links to flash. The problem is because of the code below found in the Apollo Client initialisation:

  // If your page has Next.js data fetching methods that use Apollo Client, the initial state
  // gets hydrated here
  if (initialState) {
    _apolloClient.cache.restore(initialState)
  }

when we navigate to a SSG page, the getStaticProps data populates pageProps in _app and then the useApollo restores the client's cache but only with the static props data and completely wipes any existing cache items that might have been there. has anyone found a way to solve this? merging the pageProps created by the SSG page and the existing cache?

[JimmyRowland]

Still broken

Thanks for the tip. For some reason, it is not working for me. If I put in initialstate/prevState, the first one will always get lost. Any suggestions?

[lfades]

@JimmyRowland Make sure to do client side transitions with next/link, as a full page refresh will reset the cache

[JimmyRowland]

In my case, prevState overwrite initiastate.ROOT_QUERY. I solved it by

[matthewlilley]

@JimmyRowland Yeah, I had to do this as well. The ROOT_QUERY was not being merged correctly, and data was merged in the wrong order causing local updates to be wiped on client transition.

[ryanagillie]

I was doing something like this, shouldn't the new cache update the old?

  if (initialState) {
    const prevState = apolloClient.extract();

    apolloClient.restore({ ...prevState, ...initialState, ...{ ROOT_QUERY: { ...prevState.ROOT_QUERY, ...initialState.ROOT_QUERY } } });
  }

[yossisp]

As far as I understand getServerSideProps pretty much makes any kind of caching client-side meaningless, right? If I have some page X which upon navigated, fetches some data with getServerSideProps then I save the data to some local cache client-side (I'm using Apollo). Then I navigate to another route, I click again on a menu link which navigates back to X then getServerSideProps will be run again even though the data already exists in the cache and potentially could be used. Is there any way to conditionally run getServerSideProps? I'm curious why was this pattern considered better than a pattern which allows to cache data locally and thus prevent requests which will fetch the same data (e.g. getInitialProps)?

[milban]

I have the same question. Using getServerSideProps causes a network call that does not need to be called again because the data already exists in cache in the client side Apollo.
Also, in the operation method like getInitialProps, you only need to hydration the data from the server side to client side Apollo once, but if you use getServerSideProps, you have to continuously hydration(merge) it. This can cause unintended bugs. For example, if a call is made with the same Query Document and the same Variables, but a random value is returned as a response, unexpected query results are created by combining Apollo's cache serialization and continuous hydaration(merge) logic.

If anyone has an answer to this, please let me know.

[mbrowne]

@yossisp Good point. I don't know of a way to solve this when it comes to queries that you want to run both during SSR and also on the client if the user goes there via client-side navigation.

But if you want a particular query to only ever be executed on the client, Apollo has a blog post that includes an example of that. In that case, useQuery would hit your GraphQL endpoint directly and/or make use of Apollo's cache in the browser.

[FahmyChaabane]

Hello from 2021,

Is there any update about this ? ( is there any way to prevent SSR request if data is already stored in client cache ? )

[pureLifeWater101]

Hello from 2022, any updates on this?

[carlosbaraza]

We decided to finally to a whole refactoring to explicitly query the data we want to SSR. The biggest risk we found is that the query down the component tree could potentially change and the query not hit the cache.

In SSR, we enabled the cache-only mode, to avoid making network requests in the actual rendering cycle:

const client = useApollo(
    pageProps.initialApolloState,
    undefined,
    isServer ? 'cache-only' : 'cache-first'
);

Now, for the queries that we want to explicitly SSR, we wrote a small hook to check that the data is returned. If the data is not returned in development, we crash the rendering to alert the developer that SSR is broken. This will crash in staging to. Note that we use graphql-codegen to generate a hook per query.

export function useSSRQuery<T extends (...args: any[]) => any>(
  useCallback: T,
  ...args: Parameters<T>
): ReturnType<T> {
  const response = useCallback(...args);

  // If not production and not server, crash the application
  // to alert the dev that SSR is not working
  if (!isProduction) {
    const isServer = typeof window === 'undefined';
    if (isServer && !response.data) {
      throw new Error(
        `SSR not functioning properly\n\n${JSON.stringify(
          { hookName: useCallback.name, args },
          null,
          2
        )}\n`
      );
    }
  }

  return response;
}

To use it we'd do something like this:

  const {
    loading,
    data,
    error
  } = useSSRQuery(useSearchResultsQuery, {
    variables
  });

This is not perfect, but at least we explicitly tell which queries we expect to SSR, and if they don't work well, we have a way to alert the user. Potentially, we could add tests or a custom error handler.

For the time being, this reduces the risk of another developer changing the query down the component tree and forgetting to update the SSR query. I don't like the way Next forces us to duplicate the query logic, which was more elegant with getDataFromTree, but at least we save one render cycle and we have more control over which queries are important for SSR and which ones are not.

Hopefully, this helps someone. Feel free to share ideas to workaround this limitation.

[mdwt]

I've been following this discussion for an SSR solution for getServerSideProps, but it's still a bit fuzzy on how to get SSR working with getServerSideProps..I've used the with-apollo example as guide but using getServerSideProps instead of getStaticProps, but I can't get next to generate the actual HTML for the fetched data server side, it only seems to send the raw data to the client and then the client generates the actual HTML..So the initial page load only contains the NextJS script includes and the raw JSON data...

A simple example would be a page for displaying products (paginated), so the initial page load contains the HTML of the first few products fetched and rendered on the server, and load more functionality is then fetched from and rendered on the client.

So if I view the generated html in a browser - I'm expecting to see the raw data that was fetched server side, as well as the HTML of the first bunch of products, but I only see the the raw data followed by the Next.js script includes in the body, no HTML of the actual data. The product cards is generated client side.

Not sure what I'm missing here - how can I force Next to generate the HTML server side instead of only sending the data.

[maticrivo]

Hi @mdwt
Have you ever found an answer for this?
I'm facing the same issue...

[TheRusskiy]

I am experimenting with the following approach, so far seems to allow both static rendering and avoids having to manually prefetch queries in getStaticProps.

In order to fetch all the nested queries we don't need to render the whole app, we can render the page component.
However, in order to render it we need a router and since we don't have ctx like with getInitialProps we don't have the router and all useRouter calls fail.

And we can't create a "true" ServerRouter

next.js/packages/next/next-server/server/render.tsx

Lines 511 to 522 in 48acc47

	const router = new ServerRouter(
	pathname,
	query,
	asPath,
	{
	isFallback: isFallback,
	},
	basePath,
	renderOpts.locale,
	renderOpts.locales,
	renderOpts.defaultLocale
	)

because getStaticProps doesn't get enough props:

next.js/packages/next/next-server/server/render.tsx

Lines 598 to 606 in 48acc47

	data = await getStaticProps!({
	...(pageIsDynamic ? { params: query as ParsedUrlQuery } : undefined),
	...(previewData !== false
	? { preview: true, previewData: previewData }
	: undefined),
	locales: renderOpts.locales,
	locale: renderOpts.locale,
	defaultLocale: renderOpts.defaultLocale,
	})

However, I wonder if we really need the whole router or we just need params and locales from it:

next.js/packages/next/next-server/lib/router/router.ts

Lines 250 to 259 in 48acc47

	export type BaseRouter = {
	route: string
	pathname: string
	query: ParsedUrlQuery
	asPath: string
	basePath: string
	locale?: string
	locales?: string[]
	defaultLocale?: string
	}

With that in mind, here's my prototype:

import { GetStaticPathsResult, NextPage } from "next";
import { ApolloProvider, gql, useQuery } from "@apollo/client";
import { withApollo } from "components/withApollo";
import CurrentUser from "components/CurrentUser";
import { useRouter } from "next/router";
import {
  productPageQueryType,
  productPageQueryVariablesType,
} from "./types/query";
import apolloStatic from "components/withApollo/apolloStatic";

type Params = {
  seoName: string;
};

const QUERY = gql`
  query productPage($seoName: String!) {
    product(seoName: $seoName) {
      id
      name
    }
  }
`;

function ProductPage() {
  const router = useRouter();
  const { seoName } = router.query as Params;
  const { data } = useQuery<
    productPageQueryType,
    productPageQueryVariablesType
  >(QUERY, {
    variables: {
      seoName,
    },
    fetchPolicy: "cache-and-network",
  });
  const product = data?.product;
  if (!product) {
    return <div>Not Found</div>;
  }
  return (
    <div>
      {/* CurrentUser has "skip: typeof window === 'undefined'" in its query */}
      <CurrentUser />
      <Title>
        Product: {product.id} {product.name}
      </Title>
    </div>
  );
}

export default withApollo({ ssr: false })(ProductPage as NextPage);

export async function getStaticPaths(): Promise<GetStaticPathsResult> {
  return {
    paths: [],
    fallback: "blocking",
  };
}


// TODO: extract this boilerplate into a helper
export const getStaticProps = async ({
  params,
  locales,
  locale,
  defaultLocale,
}) => {
  const { getDataFromTree } = await import("@apollo/react-ssr");
  const { RouterContext } = await import(
    "next/dist/next-server/lib/router-context"
  );
  const router = {
    query: params,
    locales,
    locale,
    defaultLocale,
  };
  const apolloClient = apolloStatic();

  const PrerenderComponent = () => (
    <ApolloProvider client={apolloClient}>
      <RouterContext.Provider value={router}>
        <ProductPage />
      </RouterContext.Provider>
    </ApolloProvider>
  );

  await getDataFromTree(<PrerenderComponent />);

  return {
    props: {
      apolloState: apolloClient.cache.extract(),
    },
  };
};

One notable omission is the absence of pathname in the fake router.

[felixmeziere]

Same problem here trying to use Apollo with getServerSideProps without re-fetching and displaying loading state after site load...

[mpoisot]

@TheRusskiy did the /products/[seoName] page render nested Apollo queries using getDataFromTree() without any private API hacks like the one you used earlier in this thread? If so that alone is a breakthrough.

I wonder if you could re-enable static rendering on the other pages by adding a dummy getStaticProps() to each page? That would be annoying and ugly but at least it would be easy.

Does anyone know if the mysterious behavior of defining _app.getInitialProps() plus getStaticProps() on a page is officially documented anywhere? Or if it's even on purpose? I would think it's a bug, since if you try to define both of those functions on one Page you get an error.

[TheRusskiy]

@mpoisot you don't have to use the

  const { RouterContext } = await import(
    "next/dist/next-server/lib/router-context"
  );

Technically it's possible to render without it, but you have to say goodbye to all the useRouter calls, which I don't think is acceptable. So have to use this private API for now.

[drewlustro]

@lfades @TheRusskiy

That's not the case if the page has getStaticProps 👍

So wait... was this comment actually true? I'm facing the same issue.

My understanding is that if one defines App.getInitialProps, it opts out the entire application from static generation.

[TheRusskiy]

@drewlustro in my experiments the static generation was disabled. Not sure if something has changed since.

[ziimakc]

As i can see there is no way to solve @yossisp issue with getStaticProps and getServerSideProps graphql cache :(

Going to read about gutsby for now, maybe they have a working way with ssg/ssr and graphql.

[adamsoffer]

@ziimakc yeah graphql is a first class citizen in Gatsby. Graphql queries anywhere in the component tree get fetched out of the box. Would love to see graphql get a little more attention in Next.js

[ziimakc]

Created fuature request to make it work at least somehow: #19611

[msreekm]

So no solution for getServerSideProps to use the apollo client cache and eliminate the extra extra network call? does this mean we are sticking to getInitialProps ?

[ziimakc]

yep

[lukel97]

@TheRusskiy Thanks for sharing your example. I was able to modify it to work with getServerSideProps, and came up with this wrapper:

export function withGraphQL<P, IP>(Page: NextPage<P, IP>): NextPage<P & { apolloClient?: ApolloClient<NormalizedCacheObject>, apolloState?: NormalizedCacheObject }, IP> {
  return (props) => {
    const client = props.apolloClient ?? userGraphQLClient()
    if (!props.apolloClient)
      client.restore(props.apolloState)
    return (
      <ApolloProvider client={client}>
        <Page {...props} />
      </ApolloProvider>
    )
  }
}

export function getServerSidePropsWithGraphQL<P, Q extends ParsedUrlQuery>(Page: NextPage<P>, getServerSideProps: GetServerSideProps<P, Q>): GetServerSideProps<P, Q> {
  return async (ctx) => {
    const { getDataFromTree } = await import('@apollo/client/react/ssr')
    const apolloClient = userGraphQLClient(ctx)
    
    const res = await getServerSideProps(ctx)
    
    if (!('props' in res))
      return res
    
    const WrappedPage = withGraphQL(Page)
  
    await getDataFromTree(<WrappedPage {...res.props} apolloClient={apolloClient}/>)
  
    return {
      props: {
        ...res.props,
        apolloState: apolloClient.extract()
      }
    }
  }
}

Replace userGraphQLClient(ctx) with whatever you need to build your apollo client.

To use it:

export default withGraphQL(MyPage)

export const getServerSideProps: GetServerSideProps<{ foo: string }> = getServerSidePropsWithGraphQL(MyPage, async ctx => {
  return {
    props: {
      foo: 'asdf'
    }
  }
})

[pawelkrystkiewicz]

How do you run a query in getServerSideProps?

[lukel97]

@pawelkrystkiewicz we have a function that create an ApolloClient from the react context:

export const userGraphQLClient = (ctx?: NextPageContext | GetServerSidePropsContext): ApolloClient<NormalizedCacheObject> => {
...
}

so to use it from within getServerSideProps, we just pass it in the context

[vaniyokk]

There is a really annoying problem here!
Very common plugins (next-i18next, next-translate) are already dropped support for getInitialProps. All new examples are using getServerSideProps as preffered solution and there is NO WAY to eliminate extra network call every time route changed?
Nobody uses client-side cache? Hmm... don't believe.

Authors really need to think about it. I don't understand why this issue takes so little attention from community...

[Lanny]

A next-i18next upgrade is what forced this issue for me, I was able to kludge it into still working with getInitialProps. On the off chance someone needs to do the same here's an example:

Journaly/journaly@7458ebc

I do not recommend this, it's fragile and still incurs a request for translations on page changes (although that could be cached better than we're doing) but on the off chance it's useful... here it is.

[lauriskuznecovs]

What if you are forced to make a query outside of Next.js page component (./src/pages/page.js), like some nested component (./src/components/SEO.js) which should work Client and SSR?
No problem if you can query that in Next.js page component with for example getServerSideProps, but there might be cases when you cannot do that because variables are computed in deeper levels.

[chemmanouilidis]

After following the discussion I am more confused and lost than I was before I started digging on the matter. I am developping an enterprise platform in the form of a Dynamic Web App. I have already developped the Backend server using Apollo server, GraphQL and PrismaClient as an ORM to an MSSQL Database. The App is 90% dynamic meaning most of the components consist of Lists, Cards and DataTables populated on request from the backend. The dataset itsself is very fluid, meaning the results change a lot during the day, even in an hour-to-hour basis.

So coming to the frontend, the stack I decided to go with, was of course react, Apollo client, grommet for UIUX, styled components and all of them wrapped by Next.JS. I deliberately didnt choose a state management library because I wanted to use Apollo client not only for its data fetching and mutation hooks but also as a state management library using its cache. So my question is this:

How do we choose between getServerSideProps and Client Side Data fetching using Apollo? How does a page using GetServerSideProps coexist with components that use Apollo hooks to get data from or update data in the database? How can I assure that Apollo's cache will always be my single source of truth concerning state management throughout my application's lifecycle?

[chemmanouilidis]

Can you please elaborate on the "need" part of the data fetch method? Let's take for example one of my modules: A production order system of products. There is a Datatable populated by products, product details (created by clicking on the product - seperate component - product details rarely change), last order, minimum quantity (that should raise an alarm that na new production order is needed) max quantity. Based on the above model how would you choose which data to fetch with Next APIs and which data belong to Apollo Client? And what about mutations? if you mutate part of the Data you only need to update the cache with this Data? And what happens if you need to mutate Data that was populated by getStaticProps? will they be updated ?

[JClackett]

"Need" is anything you want server rendered, do you need the products list to be server rendered? basically, do you need it for SEO purposes? regarding the mutations, you can just update the local cache to see instant local updates, and then I believe the "revalidate" prop in getStaticProps will update the data after the given time set.

What I would do is, write the GraphQL query once, use that in the Next APIs data fetching methods and in the apollo react hook. This gives you server rendered data. For mutations, update the cache locally and if using getStaticProps make sure the revalidate prop is "1", so when people come to the site, it will be rebuild using the latest data from the DB (technically the second person will receive the latest data). Or just use getServerSideProps and fetch the latest data from the DB everytime.

[chemmanouilidis]

So by your perspective, since this is a web app with no need of SEO, Next.JS is not a good choice since it will only add more burdens and unnecessary boiler plate between Apollo and Next. Since a project doesn't use SEO, you are better off just using Apollo Client alone, is that correct ? Especially since I want to use Apollo for state management too.

[JClackett]

I would definitely still use Next.js regardless of ssr/seo stuff. The framework has still so many benefits, and if you don't need ssr, there's no extra boilerplate at all, just use Apollo client as you usually would.

You don't have to use getStaticProps or getServerSideProps, but it's easy enough to add it later on if you decide you do want to add ssr/ssg.

[chemmanouilidis]

So when we have to deal with Dynamic Web Apps best practice is to prioritize between data that rarely changes (like a list of items) and use getServerSideProps or getStaticProps and data that is more fluid (like any orders for those items) and fire up Apollo Client, then merge Apollo's cache with the fetched data from the next.js APIs?

If I understand that correctly, it will allow for performance benefits since every page will be ServerSide Rendered in its skeleton and then any particular components will query through apollo to construct the UI with Data. Is that correct?

[mbrowne]

I am looking for a good way to handle GraphQL queries that are needed for the overall layout, e.g. header/footer navigation. The data for the navigation menus needs to come from our GraphQL server. Ideally this query should be run in getStaticProps for every static page, and the query should also be run on the server when doing SSR—but without having to repeat the code to run that query in every single page. There seems to be no way to do this in _app.js except to use getInitialProps, which breaks SSG.

We have a React component for the layout, DefaultLayout, so I tried putting the query there, using Apollo's useQuery() hook. But that causes the query to be unnecessarily run in the browser again even though it was already executed on the server. This is because the cached data from that query never makes it into pageProps[APOLLO_STATE_PROP_NAME] (following the official example), since it was executed from a React component rather than from getStaticProps or getServerSideProps.

The only solution I can see given the current limitations of next.js is to call a helper function from every getServerSideProps or getStaticProps function that executes the global navigation query and merges the data (or alternatively the extracted Apollo cache data) from both queries—the global navigation query and the query specific to that page. How are others handling this use case?

[Vadorequest]

I've handled this case with "static data". Using https://github.com/ricokahler/next-plugin-preval

See https://github.com/UnlyEd/next-right-now/blob/v2-mst-aptd-at-lcz-sty/src/modules/core/i18n/fetchStaticLocizeTranslations.preval.ts for an example. (fetches i18n translations once before building any next.js page and shares those static data with all pages)

Data will be stale using this method, and only updated when rebuilding the whole Next.js app, but that's what I wanted.

[mbrowne]

Very interesting, I think that could work for us. Thanks!

[TheRusskiy]

@mbrowne you can also check my message in this thread: #11957 (comment)

And a github repo:
https://github.com/TheRusskiy/next-apollo-ts

[carlosjunod]

I've handled this case with "static data". Using https://github.com/ricokahler/next-plugin-preval

See https://github.com/UnlyEd/next-right-now/blob/v2-mst-aptd-at-lcz-sty/src/modules/core/i18n/fetchStaticLocizeTranslations.preval.ts for an example. (fetches i18n translations once before building any next.js page and shares those static data with all pages)

Data will be stale using this method, and only updated when rebuilding the whole Next.js app, but that's what I wanted.

thank you. this is very helpful.

[Oikio]

Just to summarize discussion and please correct me if I am wrong.
There is no method besides traversing tree with getDataFromTree to keep using Apollo for React as one coming from almost any other project would expect to.
getServerSideProps and getStaticProps will not help you in this case (unless you building something simple), because the idea behind this lib is that you can request what you need on every level of your app, hiding complexity and separating components. If tree is complex you cannot determine everything on page level.

As an example, we have a headless CMS with lots of brands and we dynamically determine what to request for url on components level, so we have only one page for most of page types - because on this level we do not know yet what kind of page it is. So we cannot make queries on page level which will fit all cases because branching is too complex.