In this article, I will discuss a common issue and best practices when using the Apollo client with Atlas, WP Engine\u2019s headless WordPress hosting platform.<\/p>\n\n\n\n
<\/p>\n\n\n\n
The Apollo client is a popular comprehensive state management library for JavaScript that enables you to manage both local and remote data with GraphQL<\/a>. It has features you can use for fetching, modifying application data, and caching. This article\u2019s focus is the caching mechanism in Apollo.<\/p>\n\n\n\n If you need foundational knowledge of Apollo, please visit their docs<\/a>.<\/p>\n\n\n\n Next.js<\/a> is the most popular open-source front-end Javascript framework. Most developers that have adopted a Headless WordPress architecture choose Next.js because it allows you to choose and pick how to render and fetch your data from WordPress. You can use Static Site Generation, Server Side Rendering, or Incremental Static Regeneration. <\/p>\n\n\n\n Out of the box, Next.js uses its Within these methods, it is common to use the WPGraphQL<\/a> API and GraphQL with Apollo to fetch the page data from WordPress. <\/p>\n\n\n\n Here is the common configuration from the Apollo docs below:<\/p>\n\n\n What you would expect when using On the flip side of that, When you use One issue we have seen developers run into is seeing stale WordPress data show up in their front-end application, something that can happen with Apollo\u2019s default caching policy. And this is not ideal when you have mission-critical sites that rely on up-to-date data as close to real-time as possible.<\/p>\n\n\n\n This is where the Apollo client configuration comes into play.<\/p>\n\n\n\n The Apollo client has its own caching mechanism and this is where the issue lies. Most people using Apollo might be unaware that when creating an Apollo custom configuration in their project, it has its own caching layer that can affect your data freshness, in relation to what hosting platform you are using. In this article\u2019s case, we are talking about the Atlas platform.<\/p>\n\n\n\n Now, some serverless platforms will naturally run the Apollo cache to be shorter-lived. In Atlas, it runs a full node server and the outcome of this is a longer-lived Apollo cache.<\/p>\n\n\n\n Our very own solutions architect Jordan Maslyn<\/a> created this code snippet for Atlas users to alleviate the issue when using Apollo:<\/p>\n\n\n Let\u2019s break down what is happening in Jordan\u2019s code snippet.<\/p>\n\n\n\n The Apollo client uses The link supports both The code block above starts with an Apollo Link that equals the new link variable and uses If set to true, The next thing to focus on is the This means that wherever an Atlas customer instantiates their Apollo client, it will bypass<\/a> the Apollo Cache. By using the \u201cnetwork-only\u201d Like everything in web development, there are tradeoffs in any approach you decide to take. Bypassing the Apollo cache will give you the up-to-date, fresh data that you require. However, the trade-off here is that you are not serving cached files which are served quicker by default.<\/p>\n\n\n\n Because you will be running the request on the server, the performance for page load is decreased and you will increase the load on your server. However, there is a new tool that can let you have both!<\/p>\n\n\n\n An option to consider is WPGraphQL Smart Cache<\/a>. This plugin captures the results of GraphQL Requests, stores the response in a cache, and uses the cached response for future requests instead of executing the query and all of its resolvers at each request. <\/p>\n\n\n\n This means you are not evening hitting your WordPress server, in turn decreasing the load and increasing your performance. Above and beyond Apollo\u2019s caching implementation, WPGraphQL Smart Cache knows when you update your content and can purge any related cached responses accordingly. <\/p>\n\n\n\n This lets you continue having the performance and scalability benefits of an API caching layer while also delivering the freshest version of your data as it is requested by your front-end application.<\/p>\n\n\n\nUsage with Next.js and Headless WordPress<\/strong><\/h3>\n\n\n\n
getStaticProps<\/code> function which is the method for statically generating your site at build time. You can also choose getServerSideProps<\/code> which is the opposite of static generation. This tells the Next.js component to populate the props and render them into a static HTML page at run time.<\/p>\n\n\n\nimport<\/span> { InMemoryCache, ApolloClient } from<\/span> '@apollo\/client'<\/span>;\n<\/span><\/span>\n<\/span><\/span>const<\/span> client = new<\/span> ApolloClient({\n<\/span><\/span> \/\/..other arguements...<\/span>\n<\/span><\/span>cache<\/span>: new<\/span> InMemoryCache(options)\n<\/span><\/span>})\n<\/span><\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\ngetStaticProps<\/code> is for the WordPress data to be fresh and updated upon every rebuild of the page and site. <\/p>\n\n\n\ngetServerSideProps<\/code> and fetch the WordPress data at runtime, you should see the fresh data immediately because the server is doing the work upon every user\u2019s request.<\/p>\n\n\n\nCatching the Apollo Cache<\/strong> \ud83d\udcb8<\/h2>\n\n\n\n
Configuration with Atlas<\/strong><\/h3>\n\n\n\n
import<\/span> {\n<\/span><\/span> ApolloClient,\n<\/span><\/span> InMemoryCache,\n<\/span><\/span> HttpLink,\n<\/span><\/span> ApolloLink,\n<\/span><\/span>} from<\/span> \"@apollo\/client\"<\/span>;\n<\/span><\/span>\n<\/span><\/span>const<\/span> link = ApolloLink.from([\n<\/span><\/span> new<\/span> HttpLink({\n<\/span><\/span> uri<\/span>: `${process.env.NEXT_PUBLIC_WORDPRESS_API_URL}<\/span>\/graphql`<\/span>,\n<\/span><\/span> useGETForQueries<\/span>:\n<\/span><\/span> process.env.CACHE_GRAPHQL_RESPONSES !== \"false\"<\/span> ? true<\/span> : false<\/span>,\n<\/span><\/span> }),\n<\/span><\/span>]);\n<\/span><\/span>\n<\/span><\/span>export<\/span> const<\/span> client = new<\/span> ApolloClient({\n<\/span><\/span> link,\n<\/span><\/span> cache<\/span>: new<\/span> InMemoryCache(),\n<\/span><\/span> defaultOptions<\/span>: {\n<\/span><\/span> query<\/span>: {\n<\/span><\/span> fetchPolicy<\/span>:\n<\/span><\/span> process.env.CACHE_GRAPHQL_RESPONSES !== \"false\"<\/span>\n<\/span><\/span> ? \"cache-first\"<\/span>\n<\/span><\/span> : \"network-only\"<\/span>,\n<\/span><\/span> },\n<\/span><\/span> },\n<\/span><\/span>});\n<\/span><\/span>\n<\/span><\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nHttpLink<\/code> to send GraphQL operations to a server over HTTP. <\/p>\n\n\n\nPOST<\/code> and GET<\/code> requests, and it can modify HTTP options on a per-query basis.<\/p>\n\n\n\nHttpLink<\/code>. The useGETForQueries<\/code> key is a constructor option that Httplink<\/code> accepts. <\/p>\n\n\n\nHttpLink<\/code> uses GET<\/code> requests instead of POST<\/code> requests to execute query operations (but not mutation operations). GET<\/code> requests can allow us to leverage some default caching from the protocol (and helps improve the performance and scalability of your WordPress server!), but if we are interested in prioritizing data freshness over performance\/scalability, we will want to disable that feature.<\/p>\n\n\n\nfetchPolicy <\/code>key. This key defines how Apollo Client uses the cache for a particular query. The default policy is cache-first, which means Apollo Client checks the cache to see if the result is present before making a network request.<\/p>\n\n\n\n
If the result is present, no network request occurs. Within the const variable that is exported as the new Apollo Client, we have an environment variable called CACHE_GRAPHQL_RESPONSES which is set to \u201cfalse\u201d. <\/p>\n\n\n\nfetchPolicy<\/code>, we can deter Apollo from caching responses which prioritizes data freshness (and allows other layers with more awareness of your content to handle the caching as discussed in the next section).<\/p>\n\n\n\nThe Trade-Off<\/strong><\/h2>\n\n\n\n
Optional Solution<\/strong>: \u26a1WPGraphQL Smart Cache \u26a1<\/h3>\n\n\n\n