Understanding Next, Apollo and Faust

I managed to get Faust updated by making a local copy, running npm update, and commiting the package.json to Git.

Though I still confused about why the build without a package.json didn’t seem to update Faust. Or perhaps it did and we were just running into the next issue?

Anyway, I’m still having issues with the Atlas Blueprint. The posts/blog page seems to update to show new posts without a build now, but the homepage does not.

In fact, there is this weird behaviour where:

• I have 8 posts total.
• The posts/blog page shows them all.
• The homepage should show posts 1-3, but it’s actually showing posts 3-5
• If I visit the blog page and then the homepage, the homepage shows posts 1-5
• If I then reload the homepage, it goes back to showing posts 3-5

So I’ve been looking through the Blueprint code to try and understand it. This is NOT easy, but here are some things I’ve found…

• There’s a pages folder and a wp-templates folder.
• The wp-templates folder is what mimics the WordPress template hierarchy.
• The wp-templates folder includes various things, but, importantly, there is no template here for the /posts route that represents my blog page.
• Instead the blog page is a Next.js page with code in the pages folder.
• Also in the pages folder is a special file called [...wordpressNode].js – I assume that this is what powers the WordPress template hierarchy behaviour. The code in this file makes use of the WordPressTemplate component that faust.js provides.
• The file pages/posts/index.js contains the code for the posts/blog page. Importantly, this HAS a getStaticProps that I’m assuming tcauses the page to be statically generated/cached.
• Compare this with the various bits of code used to render the homepage and none of these have getStaticProps

So what we know here is that the posts page is statically cached and regenerated after a set time.

But the homepage seems to be dynamically rendered (on the server).

I was chatting with Theo Despoudis in #pe-atlas-merlin and he showed me that I could add

fetchPolicy: "no-cache"

to the query setup in front-page.js and this would show me the right posts.

And it did, but it made the homepage really slow.

This is because the server-side generation is using Apollo for fetching and caching queries (Apollo is actually used on both server and client).

This fetchPolicy tells Apollo not to cache the query responses. So the homepage generation is slower.

Shall we try a full summary?

1. Posts page is statically generated and working now that the revalidate option is passed
2. Home page is dynamically (?) generated but using query data that is cached server-side
3. The Blueprint is broken – the homepage needs to purge its query cache every now and then, or be statically generated without a query cache, and with a revalidate option set.