with-apollo example is not scalable or suitable for production usage, and does not mention this

[lostfictions]

Bug report

Describe the bug

In June, the with-apollo example was updated to use the newer getStaticProps / getServerSideProps APIs rather than getInitialProps. Unfortunately, it also changed the way the example works. Previously, the with-apollo example performed a prepass to extract all Apollo queries in a React tree and execute them, and then would render the result. In this updated version of with-apollo, developers are required to manually specify all queries that exist in a React tree at the root of the tree -- that is, at the page level.

To wit, the index.js page of the example imports an ALL_POSTS_QUERY, which also lives in a component that (probably) gets rendered in the tree... somewhere.

next.js/examples/with-apollo/pages/index.js

Lines 5 to 8 in 0649176

	import PostList, {
	ALL_POSTS_QUERY,
	allPostsQueryVars,
	} from '../components/PostList'

Even in this trivial example which only uses a single query, at a glance we have no idea where or when this query is required; it's not directly rendered by the index page itself, so we'd have to have to hunt through all the child components to try to identify where it's needed (which may be in multiple places in the component tree). It should be obvious that this is extremely brittle and error-prone; if we refactor this page, it's not easy to determine which queries need to be added or removed. And if components change, queries need to be updated on all pages which could possibly render the component as a child somewhere in its tree. It's almost impossible to reason about, and feels like a return to the "bad old days" of global CSS and pre-bundler Javascript.

This appears to be a serious downgrade from the previous functionality, and I think it goes without saying that the approach of manually specifying all dependencies at the page root is a maintenance nightmare and does not scale to a serious production site. It's not clear why this is now the "blessed" approach recommended by Next (which it implicitly is by virtue of being the primary example of usage with Apollo), but the readme for the example should probably at least mention the limitations and brittleness should a developer choose to use it as a starting point.

[lostfictions]

Poking around a bit more, I see this issue was already raised in a comment on a discussion thread: #11957 (reply in thread)

(That said, it was almost impossible to find since it was downgraded to a discussion and buried in replies; I'd like to request that this issue remain an issue so that people can find it when searching, like I tried to.)

[MauritsRi]

To add to your point, there's a major performance regression in the "new" with-apollo example:

Pages with getServerSideProps will have their queries re-run every time they are accessed. Thus, for a website where users often switch pages, users are required to wait for data to be re-fetched on every page change (even if the data is already in the client-side cache!).

This is clearly noticeable in the with-apollo example when switching between the home and /about page, if you change the getStaticProps function of the index.js file to getServerSideProps. Of course, there's a use case where data should be refetched on every page navigation. Previous versions of the with-apollo example allowed fine-grained control by setting the fetchPolicy option for the relevant query. Now, there's no choice but to re-fetch the data every route change.