What is the difference of using initializeApollo on getStaticProps

[theprobugmaker]

I saw this on the api-routes-apollo-server-and-client example

next.js/examples/api-routes-apollo-server-and-client/pages/index.js

Lines 32 to 44 in 89fffa6

	export async function getStaticProps() {
	const apolloClient = initializeApollo()
	await apolloClient.query({
	query: ViewerQuery,
	})
	return {
	props: {
	initialApolloState: apolloClient.cache.extract(),
	},
	}
	}

But on the api-routes-apollo-server-and-client-auth example it doesn't exist.

But in both in the _app.js:

next.js/examples/api-routes-apollo-server-and-client/pages/_app.js

Lines 4 to 12 in 89fffa6

	export default function App({ Component, pageProps }) {
	const apolloClient = useApollo(pageProps.initialApolloState)
	return (
	<ApolloProvider client={apolloClient}>
	<Component {...pageProps} />
	</ApolloProvider>
	)
	}

What about the usage of getServerSideProps for example to redirect the user instead of doing like this in the auth example:

next.js/examples/api-routes-apollo-server-and-client-auth/pages/index.js

Lines 22 to 49 in 89fffa6

	useEffect(() => {
	if (shouldRedirect) {
	router.push('/signin')
	}
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [shouldRedirect])
	if (error) {
	return <p>{error.message}</p>
	}
	if (viewer) {
	return (
	<div>
	You're signed in as {viewer.email} goto{' '}
	<Link href="/about">
	<a>about</a>
	</Link>{' '}
	page. or{' '}
	<Link href="/signout">
	<a>signout</a>
	</Link>
	</div>
	)
	}
	return <p>Loading...</p>
	}

What are the differences of doing the redirect directly in the page, calling initialApolloState on the getStaticProps and using getServerSideProps in this situation?

[theprobugmaker]

@lfades Sorry for pinging you here but I guess that you were the one that made the example. If you can explain I would appreciate a lot, it would help me a lot.

[lfades]

Hi @zefexdeveloper this is a very good question. I'll try to give you a very detailed answer 😌

api-routes-apollo-server-and-client is using getStaticProps in pages/index.js to add Static Generation to the page, this is good because the data for the page in this case is known at build time, therefore we can pregenerate the page and serve the same static files to the users using the site.

The page in question seems to be rendering user info, but that example doesn't have authentication, we could probably just update it for a more clear use case.

About _app.js, in both examples, and in all Apollo examples, takes care of starting the global Apollo client that can be used for all pages, it will also merge initial state that may be returned by a page using a data fetching method, like getStaticProps / getServerSideProps, but without forcing you do use them, so it will basically work with any kind of page. That's why you can see that one example is using getStaticProps while the other one is not, you're free to handle data in whatever way you want.

Now why is api-routes-apollo-server-and-client-auth not using getStaticProps?
Because the data is not known at build time, it depends on user info that we don't know and can be very different depending on who is using the site, so the best thing to do here is to wait for the page to be rendered, and then using client side data fetching (in this case with SWR) we add the user data. Because the initial HTML doesn't provide this data, you can still serve static files that will be the same for anyone using the site, and are very fast, and then handle a loading state while the user data is being fetched

[lfades]

Yes 👍

[Albert-Gao]

I think I am picking up the new approach here:

Previously with getInitialProps, the lifecycle (for a full refresh) is

1. client sends a request
2. server SSR with data
3. client renders the response (layout included because of SSR)
4. wait for JS to be initialized in order to interact with the page

So now the suggested way is:

1. client sends a request
2. server sends back the layout without data
3. client renders the response (layout included because of SSR)
4. wait for JS to be initialized in order to interact with the page
5. client sends another request in order to get data to render the page

TBH, this method is nearly as same as the setup of a PWA without SSR (like Twitter is using react native web and PWA without SSR as I am aware of), I can still see 2 benefits here:

• render after refreshing is arguably faster but depends on network speed
• no TTI problem which can not be solved on SSR-with-data, but SPA has no TTI problem as well

It should visually faster than the traditional SSR-with-data, because it is faster

then the question is what is the suggested way of returning the layout (let's say return a page with loading spinner) only without data? How could getStaticProps solve the problem?

@lfades sorry for the chime in, just want to understand more about the getStaticProps as I still have questions unanswered from that removing-getInitialProps-example-issue :D

[lfades]

then the question is what is the suggested way of returning the layout (let's say return a page with loading spinner) only without data? How could getStaticProps solve the problem?

@Albert-Gao Not sure I understand your question, but in any case, getStaticProps will not have a loading state unless getStaticPaths is added and it returns fallback as true, in any other case getStaticProps will always generate the content at build time.

Pages without getStaticProps will also be static, you can handle the loading state in any way you want.

[sushilbansal]

api-routes-apollo-server-and-client is using getStaticProps in pages/index.js to add Static Generation to the page, this is good because the data for the page in this case is known at build time, therefore we can pregenerate the page and serve the same static files to the users using the site.

It is a user info and depends upon the whether user is logged in or not? How we can statically generate any page which is dependent on user info?

[lfades]

@sushilbansal You can opt for generating static HTML for the data of the page that's not tied to the user (like a blog post), and then fetch user related data on the client using something like SWR (https://swr.vercel.app/), like your user profile in the nav bar.