{"cache":{"posts1":{"__typename":"RootQueryToPostConnection","nodes":[{"__typename":"Post","id":"cG9zdDo3OTY=","uri":"/catching-the-cache-using-the-apollo-client-and-next-js-on-atlas/","seo":{"__typename":"PostTypeSEO","readingTime":6,"opengraphDescription":"In this article, I will discuss a common issue and best practices when using the Apollo client with Atlas, WP Engine’s headless WordPress hosting platform. The Apollo Client 🧑‍🚀 The Apollo client is a popular comprehensive state management library for JavaScript that enables you to manage both local and remote data with GraphQL. It has […]"},"author":{"__typename":"NodeWithAuthorToUserConnectionEdge","node":{"__typename":"User","id":"dXNlcjo3","avatar0":{"__typename":"Avatar","url":"https://secure.gravatar.com/avatar/c24a68b84c9ad2b53c633d14917d8298?s=96&d=mm&r=g"},"name":"Francis Agulto","description":"---\r\ntitle: Developer Advocate\r\n---","seo":{"__typename":"SEOUser","social":{"__typename":"SEOUserSocial","twitter":""}}}},"title0":"Catching The Cache using the Apollo Client and Next.js on Atlas","date":"2022-12-01T13:58:58","content0":"\n

In this article, I will discuss a common issue and best practices when using the Apollo client with Atlas, WP Engine’s headless WordPress hosting platform.

\n\n\n\n

The Apollo Client 🧑‍🚀

\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. It has features you can use for fetching, modifying application data, and caching. This article’s focus is the caching mechanism in Apollo.

\n\n\n\n

If you need foundational knowledge of Apollo, please visit their docs.

\n\n\n\n

Usage with Next.js and Headless WordPress

\n\n\n\n

Next.js 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.

\n\n\n\n

Out of the box, Next.js uses its getStaticProps function which is the method for statically generating your site at build time. You can also choose getServerSideProps 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.

\n\n\n\n

Within these methods, it is common to use the WPGraphQL API and GraphQL with Apollo to fetch the page data from WordPress.

\n\n\n\n

Here is the common configuration from the Apollo docs below:

\n\n\n\n

import { InMemoryCache, ApolloClient } from '@apollo/client';\n\nconst client = new ApolloClient({\n   //..other arguements...\ncache: new InMemoryCache(options)\n})

\n\n\n\n

What you would expect when using getStaticProps is for the WordPress data to be fresh and updated upon every rebuild of the page and site.

\n\n\n\n

On the flip side of that, When you use getServerSideProps and fetch the WordPress data at runtime, you should see the fresh data immediately because the server is doing the work upon every user’s request.

\n\n\n\n

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’s 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.

\n\n\n\n

This is where the Apollo client configuration comes into play.

\n\n\n\n

Catching the Apollo Cache 💸

\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’s case, we are talking about the Atlas platform.

\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.

\n\n\n\n

Configuration with Atlas

\n\n\n\n

Our very own solutions architect Jordan Maslyn created this code snippet for Atlas users to alleviate the issue when using Apollo:

\n\n\n\n

import {\n  ApolloClient,\n  InMemoryCache,\n  HttpLink,\n  ApolloLink,\n} from \"@apollo/client\";\n\nconst link = ApolloLink.from([\n  new HttpLink({\n    uri: `${process.env.NEXT_PUBLIC_WORDPRESS_API_URL}/graphql`,\n    useGETForQueries:\n      process.env.CACHE_GRAPHQL_RESPONSES !== \"false\" ? true : false,\n  }),\n]);\n\nexport const client = new ApolloClient({\n  link,\n  cache: new InMemoryCache(),\n  defaultOptions: {\n    query: {\n      fetchPolicy:\n        process.env.CACHE_GRAPHQL_RESPONSES !== \"false\"\n          ? \"cache-first\"\n          : \"network-only\",\n    },\n  },\n});\n

\n\n\n\n

Let’s break down what is happening in Jordan’s code snippet.

\n\n\n\n

The Apollo client uses HttpLink to send GraphQL operations to a server over HTTP.

\n\n\n\n

The link supports both POST and GET requests, and it can modify HTTP options on a per-query basis.

\n\n\n\n

The code block above starts with an Apollo Link that equals the new link variable and uses HttpLink. The useGETForQueries key is a constructor option that Httplink accepts.

\n\n\n\n

If set to true, HttpLink uses GET requests instead of POST requests to execute query operations (but not mutation operations). GET 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.

\n\n\n\n

The next thing to focus on is the fetchPolicy 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.

\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 “false”.

\n\n\n\n

This means that wherever an Atlas customer instantiates their Apollo client, it will bypass the Apollo Cache. By using the “network-only” fetchPolicy, 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).

\n\n\n\n

The Trade-Off

\n\n\n\n

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.

\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!

\n\n\n\n

Optional Solution: ⚡WPGraphQL Smart Cache ⚡

\n\n\n\n

An option to consider is WPGraphQL Smart Cache. 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.

\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’s caching implementation, WPGraphQL Smart Cache knows when you update your content and can purge any related cached responses accordingly.

\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.

\n\n\n\n

I go into detail about it in my blog post! Please consider this as an option, as this will provide an optional solution for the long-running Apollo Cache on Atlas.

\n\n\n\n

Conclusion 🚀

\n\n\n\n

The powerful combination of Next.js, the Apollo Client, and WPGraphQL can give your developers an amazing developer experience as well as give your users an amazing experience when requesting information from your apps and sites built on these tools.

\n\n\n\n

When using WP Engine’s Atlas, we want to ensure that the tools you use on our platform are fully optimized within the use case of your site especially when it comes to the caching layer, a crucial component of any web development architecture.

\n\n\n\n

Hopefully, if you are an Atlas customer or considering using Atlas and are choosing Next.js and Apollo, you find this helpful. Special thanks to Jordan Maslyn! As always, let us know your thoughts, feedback, and suggestions in our discord! Stoked!

\n","slug":"catching-the-cache-using-the-apollo-client-and-next-js-on-atlas"},{"__typename":"Post","id":"cG9zdDo3Mjc=","uri":"/wpgraphql-smart-cache-with-next-js-and-apollo/","seo":{"__typename":"PostTypeSEO","readingTime":13,"opengraphDescription":"In this article, I will discuss the WPGraphQL SmartCache plugin, its main features, what problems it solves and how to use it with a Next.js frontend and the Apollo client. Essentially, you can use any front-end framework of your choice since the Smart Cache plugin is configured to work with all of them. This will […]"},"author":{"__typename":"NodeWithAuthorToUserConnectionEdge","node":{"__typename":"User","id":"dXNlcjo3","avatar0":{"__typename":"Avatar","url":"https://secure.gravatar.com/avatar/c24a68b84c9ad2b53c633d14917d8298?s=96&d=mm&r=g"},"name":"Francis Agulto","description":"---\r\ntitle: Developer Advocate\r\n---","seo":{"__typename":"SEOUser","social":{"__typename":"SEOUserSocial","twitter":""}}}},"title0":"WPGraphQL Smart Cache with Next.js and Apollo","date":"2022-11-10T23:29:22","content0":"\n

In this article, I will discuss the WPGraphQL SmartCache plugin, its main features, what problems it solves and how to use it with a Next.js frontend and the Apollo client. Essentially, you can use any front-end framework of your choice since the Smart Cache plugin is configured to work with all of them.

\n\n\n\n

This will be a higher-level overview of the plugin. A deeper dive into all its features and capabilities are discussed in its repository in the readme file.

\n\n\n\n

If you do want to follow along in this blog post, you will need the following prerequisites:

\n\n\n\n

A WP Engine account and WP install
WPGraphQL plugin downloaded and activated
WPGraphQL SmartCache plugin downloaded and activated

\n\n\n\n

WPGraphQL/GraphQL

\n\n\n\n

Before we dive into the cache, we need to understand what WPGraphQL and GraphQL are. GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. In other words, it takes any database and throws a schema on it that exposes it visually as a graph which makes your data descriptions easy to understand.

\n\n\n\n

The image below is an example of this in WordPress with the WP data being exposed in a schema and being able to ask for exactly what you want and getting it back in the exact shape.

\n\n\n\n

\n\n\n\n

WPGraphQL is also optimized for performance using the DataLoader method and other techniques as discussed on wpgraphql.com However, there are still issues you can run into.

\n\n\n\n

Over-Queries to WordPress and Fresh Data

\n\n\n\n

As stoked as I am on WPGraphQL, it has some common issues when developers use it to decouple WordPress.

\n\n\n\n

Anytime you make a request to the WordPress backend via WPGraphQL, there is a cost you will pay to make that request performance-wise. If you query WordPress too much, you will timeout your WordPress server. There are ways around this, especially when using Next.js which I discuss here.

\n\n\n\n

The other issue that is a general difficulty in web development is invalidating the cache to get fresh, up-to-date data and then making it performant for speed.

\n\n\n\n

Thanks to the WPGraphQL Smart Cache plugin, we now have a solution for these common issues.

\n\n\n\n

WPGraphQL SmartCache

\n\n\n\n

WPGraphQL SmartCache is the latest plugin in the WPGraphQL ecosystem that allows you to cache your GraphQL requests from WordPress. Once they are cached, they do not hit the WordPress server, they hit WPGraphQL SmartCache. This way, you get better performance and use fewer resources on the WordPress end! Stoked! 🎉

\n\n\n\n

The plugin is engineered so that it works specifically with your WordPress hosting platform’s network caching layer. Of course, the plugin’s first integration support is with WP Engine’s cache layer which is Varnish.

\n\n\n\n

For now, just to clarify, 3 features that will work currently on any hosting platform that we are about to dive into in this article are:

\n\n\n\n

Object Cache
Persisted Queries
Cache Invalidation

\n\n\n\n

Host Specific supported features:

\n\n\n\n

Network Cache (Varnish in WP Engine’s case)
And all of the above of course on any host-supported features

\n\n\n\n

The network cache and cache invalidation will only work on supported hosts, but there are still benefits for sites on any host as stated.

\n\n\n\n

I have an account on WP Engine with the plugins I need to make this work as stated at the beginning of the article on my WP install. Let’s dive into the features now of the plugin!

\n\n\n\n

Cache Miss/Cache Hit

\n\n\n\n

If you publish a post that’s brand new, you want that to be updated right away. When you update it, this will be a cache miss because the actual WordPress server will run those queries. WPGraphQL SmartCache understands what query was executed and then it determines what actions it should listen to within that new data action, in order to make the query.

\n\n\n\n

Let’s see this in action in an image here with our dev console open in my browser once I visit the URL for the GraphQL query. The URL I am hitting is https://buddydemo1.wpengine.com/graphql?query={posts{nodes{title}}} (Note that I am using a browser that is not authenticated to my WordPress site):

\n\n\n\n

\n\n\n\n

This query is simple. I am asking for all my post titles, utilizing the HTTP GET method. In order to maximize the optimizations of the Smart Cache plugin, I am using GET. Since this is a brand-new request, it will be a cache miss as shown.

\n\n\n\n

*** ⚠️ Just a note, if you must use POST requests which is not the recommended method, please see Object Cache in the readme for more information on how to enable this ***

\n\n\n\n

After the initial cache miss, every subsequent request of this query is cached on WP Engine with SmartCache to optimize the speed ( image shows 36 ms! 🚅) and performance of your GraphQL query without hitting your WordPress server. This is just being served from the cache!! See the images below:

\n\n\n\n

\n\n\n\n

\n\n\n\n

Cache Invalidation

\n\n\n\n

Two of the hardest things in web development are cache invalidation and naming things. Most developers will tell you that. Let’s see how cache invalidation works in WPGraphQL SmartCache. In this image, look at the first post title:

\n\n\n\n

\n\n\n\n

My title has 2 exclamation marks. Let’s change that data in our WP Admin and see what happens.

\n\n\n\n

\n\n\n\n

I changed my first post title. You can see that it reflects in the JSON as well the headers. WPGraphQL SmartCache listened to the event change in WordPress, realized that it was a data change, and invalidates the cache allowing WordPress to serve accurate data. Cache Miss Stoke! The response time for this miss was 479ms

\n\n\n\n

\n\n\n\n

After the cache is invalidated due to the update, the request and query are now cached and every request from then on will not hit your WordPress server. This takes advantage of the network cache layer and gets accurate data upon changes.

\n\n\n\n

This is such a game-changer, allowing developers to offset the responsibility of toiling with cache invalidation to the Smart Cache plugin! Jamstoked indeed! 😄 🕺🏾

\n\n\n\n

Persisted Queries

\n\n\n\n

A persisted query is a query string that is cached on the server side, along with a unique identifier. Clients can send this identifier instead of the corresponding query string, thus reducing request sizes dramatically (response sizes are unaffected). This is a major benefit of using persisted queries since large queries can become bottlenecks for client performance.

\n\n\n\n

WPGraphQL Smart Cache provides support for persisted queries and can be used seamlessly with Apollo Persisted Queries Link. This also can be done on any hosting provider as well via POST request.

\n\n\n\n

Let’s see how this feature works. In your WP Admin, go to the left hamburger menu and find GraphQL. Once there, navigate to Settings > Saved Queries. You should see an option to “Display saved query in documents in admin editor” as shown. Check that box:

\n\n\n\n

\n\n\n\n

When you check that box, you will see a new post type in the sidebar menu called GraphQL Documents:

\n\n\n\n

\n\n\n\n

This is a familiar editing UI now, just like how you edit posts, but in this case, it is your GraphQL document. There are a few ways you can identify your unique persisted query. Let’s do Alias Names for this example.

\n\n\n\n

The first step is to go to my GraphiQL IDE and grab a copy the query I created to grab all my posts titles.

\n\n\n\n

\n\n\n\n

Once I have copied my query, the second step is to navigate back to GraphQL Documents post type, click on edit, and start filling out the fields.

\n\n\n\n

\n\n\n\n

The first field is the title field which I named “Get Post Titles.” You can name it anything you like, whether it is the actual operation name of the document or something that will remind you of what this query document does.

\n\n\n\n

The second field is the actual document field of what the query string is in an JSON object. This query string is asking for all post titles.

\n\n\n\n

Lastly, there is a description field to add any description you prefer for your own reference.

\n\n\n\n

WPGraphQL Smart Cache gives each of your individual GraphQL documents an Alias Name or ID as you can see on the right-hand side of the image on the menu. We will manually change this default Query ID to the name of our choosing. (naming things is so hard in software engineering 😂) In this case, getPostsTitles. Once I fill that field in and click add, it will add that name to this document:

\n\n\n\n

\n\n\n\n

Stoked!!! Now let’s go back to the browser, and change the end of our original URL at the beginning of this article to our Alias Name as the value which will be getPostsTitles and execute to see if it works:

\n\n\n\n

\n\n\n\n

It worked!! Instead of the object, I had in there, the Alias Name we made manually works the same. We now have this document persisted on our server and reduced an upload cost as well as avoiding a long query string with our Alias Name! 🚀

\n\n\n\n

This was just a snippet of what you can do with persisted queries on WPGraphQL Smart Cache. I encourage you to dive into all of it on the readme and repo.

\n\n\n\n

Usage with Next.js, Apollo, and ISR

\n\n\n\n

We enabled some key features on our WP Engine install with WPGraphQL Smart Cache. The last thing we need to do to make this come together is to consume that WordPress data on our front end. Let’s use Next.js and its hybrid rendering pattern, ISR with the Apollo Client.

\n\n\n\n

If you want to follow along with the front-end side of things, you can clone my repository here.

\n\n\n\n

Apollo Client Configuration

\n\n\n\n

In my frontend code, I am using the Apollo GraphQL client to optimize its features to grab the data on the client. WPGraphQL Smart Cache plays nicely with Apollo and in this example, this is the code for my apollo.js file in the lib folder:

\n\n\n\n

import {\n  ApolloClient,\n  ApolloLink,\n  HttpLink,\n  InMemoryCache,\n} from \"@apollo/client\";\n\nconst link = ApolloLink.from([\n  new HttpLink({\n    uri: `${process.env.NEXT_PUBLIC_WORDPRESS_API_URL}/graphql`,\n    useGETForQueries: true,\n  }),\n]);\n\nexport const client = new ApolloClient({\n  link,\n  cache: new InMemoryCache(),\n  defaultOptions: {\n    query: {\n      fetchPolicy: \"network-only\",\n    },\n  },\n});\n

\n\n\n\n

The first const is setting our link as ApolloLink. We set this as the HTTP link to process the graphql endpoint from WordPress which contains our data. Then, we put a key to use the useGETForQueries constructor as a fetch option because we want that for optimal performance on the Smart Cache plugin.

\n\n\n\n

The second const is exporting the Apollo Client, and configuring it as \"network-only\" so that it becomes a fetch mechanism exclusively with the cache being now handled by varnish and WP Engine.

\n\n\n\n

Dynamic Route File and ISR

\n\n\n\n

Now that we have the Apollo Client configured, the next step is to set up how often we want Next.js to rebuild the page and get fresh data. This is set on an interval in time of seconds. This can be done using their ISR data fetching method.

\n\n\n\n

I will add this timed interval in my dynamic route file which uses the slug as a parameter in the [slug].js file at the bottom in my getStaticProps function:

\n\n\n\n

import { client } from \"../lib/apollo\";\nimport { gql } from \"@apollo/client\";\nimport Head from \"next/head\";\n\nexport default function SlugPage({ post }) {\n  return (\n    <div>\n      <Head>\n        <title>Headless WP Next Starter</title>\n        <link rel=\"icon\" href=\"favicon.ico\"></link>\n      </Head>\n\n      <main>\n        <div className=\"siteHeader\">\n          <h1 className=\"title\">{post.title}</h1>\n          <p>\n            ✍️ &nbsp;&nbsp;\n            {`${post.author.node.firstName} ${post.author.node.lastName}`} | 🗓️\n            &nbsp;&nbsp;{new Date(post.date).toLocaleDateString()}\n          </p>\n        </div>\n        <article dangerouslySetInnerHTML={{ __html: post.content }}></article>\n      </main>\n    </div>\n  );\n}\n\nexport async function getStaticProps({ params }) {\n  const GET_POST = gql`\n    query PostBySlug($id: ID!) {\n      post(id: $id, idType: SLUG) {\n        title\n        content\n        date\n        author {\n          node {\n            firstName\n            lastName\n          }\n        }\n      }\n    }\n  `;\n  //  the params argument for this function corresponds to the dynamic URL segments\n  //  we included in our page-based route. So, in this case, the `params` object will have\n  //  a property named `uri` that contains that route segment when a user hits the page\n  const response = await client.query({\n    query: GET_POST,\n    variables: {\n      id: params.slug,\n    },\n  });\n  const post = response?.data?.post;\n\n  return {\n    props: {\n      post,\n    },\n    revalidate: 5,\n  };\n}\n

\n\n\n\n

At the very bottom, you can see that I added the revalidate prop and set it to a 5-second interval. This will trigger a regeneration of this post detail page. Combined with WPGraphQL Smart Cache, the instant and freshly updated data will be received and rendered quickly and cached after that.

\n\n\n\n

On your own project or if you cloned down my Next.js. starter, give it a try. Run the command npm run build in your terminal to run a production build of your site. Then run the command npm run start, pull up the browser, and go to a post detail page.

\n\n\n\n

Then go back to WP Admin, edit the post you are on, and see how fast it revalidates and updates to the latest post. Then, once it’s cached, the request is instant as displayed here:

\n\n\n\n

\"\" — Speedy and Performant Invalidation and Response! 🚀

\n\n\n\n

Conclusion…

\n\n\n\n

The WPGraphQL Smart Cache plugin is a tool that supports and solves cache invalidation and caching optimally for WPGraphQL queries. The nuance and difficulty of cache invalidation within Headless WordPress have just gotten easier thanks to Jason Bahl and Mark Kelnar.

\n\n\n\n

I touched on some high-level key features of the plugin, I encourage everyone to dive into the repo and readme as mentioned to get their hands dirty and explore all the other awesome features in this plugin.

\n\n\n\n

There are more changes and updates to come. So as always stay tuned! We also would love to hear your feedback, thoughts, and projects you are doing in Headless WordPress so hit us up in our Discord!

\n","slug":"wpgraphql-smart-cache-with-next-js-and-apollo"},{"$ref":"$[\"cache\"][\"posts1\"][\"nodes\"][1]"},{"$ref":"$[\"cache\"][\"posts1\"][\"nodes\"][1]"},{"__typename":"Post","id":"cG9zdDo3MTI=","slug":"seo-in-headless-wordpress-with-yoast-next-js-and-wpgraphql","seo":{"__typename":"PostTypeSEO","readingTime":10,"opengraphDescription":"In this article, I will discuss the topics and concepts that you will need to understand when considering and planning for Atlas as your Headless WordPress platform. Additionally, as you think about workflows, CI/CD, developer team structure, and developing on Atlas as a whole, I will go over several strategies and considerations that can help […]"},"title0":"SEO in Headless WordPress with Yoast, Next.js and WPGraphQL","uri":"/seo-in-headless-wordpress-with-yoast-next-js-and-wpgraphql/","author":{"__typename":"NodeWithAuthorToUserConnectionEdge","node":{"__typename":"User","id":"dXNlcjo3","avatar0":{"__typename":"Avatar","url":"https://secure.gravatar.com/avatar/c24a68b84c9ad2b53c633d14917d8298?s=96&d=mm&r=g"},"name":"Francis Agulto","description":"---\r\ntitle: Developer Advocate\r\n---","seo":{"__typename":"SEOUser","social":{"__typename":"SEOUserSocial","twitter":""}}}},"date":"2022-10-18T18:57:15","content0":"\n

In this article, I will discuss the topics and concepts that you will need to understand when considering and planning for Atlas as your Headless WordPress platform. Additionally, as you think about workflows, CI/CD, developer team structure, and developing on Atlas as a whole, I will go over several strategies and considerations that can help guide you.

\n\n\n\n

If you have not yet tested or developed on Atlas, please access a free developer sandbox account here.

\n\n\n\n

If you are new to Headless WordPress or Atlas, please reference these guides: Atlas, Headless WordPress Roadmap

\n\n\n\n

Building a website in Headless WordPress

\n\n\n\n

The approach of building a Headless WordPress website is different from traditional WordPress in that Headless does not require that the requested data be created and then sent to the server to be processed. Rather, the data is pre-compiled and is made available to the browser through the Content Delivery Network, or CDN for short.

\n\n\n\n

This rendering begins with your modern JavaScript framework of choice pre-building your files (JavaScript, HTML, etc). It is important that the framework chosen supports static site generation, regardless of which rendering pattern you use. Once the files are generated, you can deploy them on the CDN.

\n\n\n\n

What this does is it removes the need for the browser to go through a long and time-consuming series of interactions between the server, database, and cache, improving the performance and speed of the website.

\n\n\n\n

In a traditional monolithic workflow, you have a developer writing code and programming the site. Then they ship it to the server where the server does the work of producing the HTML requested by the client and shipping that to the client. This is done upon every client-side request.

\n\n\n\n

One key decision in the planning of a Headless WordPress site is which files the developer chooses to generate at runtime versus generating them at build time. The decision to generate your files at build time or server-side rendering them at runtime may depend on several factors – how much content can be delivered statically, requirements for dynamic content (dynamic pages or smaller dynamic components, and performance needs).

\n\n\n\n

There is the flexibility of using different rendering patterns in Headless WordPress with your choice of a JavaScript framework, however, the foundation of the Jamstack or decoupled methodology is to pre-render as much content as possible during build time.

\n\n\n\n

Workflow Steps in using Atlas

\n\n\n\n

Here are the major line items you and your teams must decide when approaching a plan to build Headless WordPress on Atlas:

\n\n\n\n

Choose a front-end JS framework like Faust.js, Next.js, Vue, etc. Oftentimes this may be based on what you and your team are familiar with. Also consider some of the features of WordPress that the Publishers may require (post previews, sitemaps) and ensure the framework supports these.
Choose your WordPress API whether that is WP REST or WPGraphQL. Both can be used and if you need help deciding, please reference this article. If you have a preexisting WP install and want to migrate the data you can easily do so with the migration plugin via WP Engine.
Ensure your front-end code is in GitHub and is integrated with Atlas.
Create any Markdown files necessary on your front end and render the data to the files. This is outside any dynamic content to be rendered at runtime.
Lastly, push changes in GitHub and deploy to Atlas.

\n\n\n\n

Atlas Abstract: What it provides

\n\n\n\n

When you adopt Headless WordPress and choose Atlas, you not only get the Atlas platform, an ecosystem of defined tooling such as a CDN and infrastructure, but Atlas also supplies a lot of moving parts in the abstract. These layers that are abstracted allow developers to have a seamless workflow and experience without having to use multiple vendors, systems, etc. Let’s get into details on what Atlas provides and things you should consider.

\n\n\n\n

Continuous Integration/Continous Deployment

\n\n\n\n

One of the most difficult things you can do as a developer is to set up a build system and CI/CD pipeline. There is a lot of toil in this workflow that most developers do not want to do. This is why the emergence of services-hosted platforms, such as Atlas, has taken their place in the market. Fully managed, taking care of this all for you.

\n\n\n\n

The Atlas platform has a simple one-click connection to your Github making it painless to integrate with your repository.

\n\n\n\n

Other services (such as AWS) may allow you to select your own deployment zone, however, with Atlas, the CDN and the target are baked in. You are provided with everything you need to build and host your Headless site.

\n\n\n\n

Atlas’s build environment gives you a secure and customizable build step. When you build your app on Atlas, it will set up your environment and server, grab any needed dependencies, run the build and deploy. It supports all tooling, front-end frameworks, site generators, etc involved in building your site. You can customize your node and yarn versions, install dependencies, create custom build and start commands as well as trigger a build with webhooks from the WordPress backend should your content editors need it.

\n\n\n\n

Atlas CDN

\n\n\n\n

A content delivery network (CDN) is a group of servers that are distributed geographically and work together to provide fast and speedy delivery of internet content. Your assets such as your HTML pages, JavaScript files, stylesheets, images, and videos are quickly transferred onto a CDN for optimal access and performance to your users.

\n\n\n\n

A properly configured CDN may also help protect websites against some common malicious attacks, such as Distributed Denial of Service (DDOS) attacks.

\n\n\n\n

A CDN can’t replace the need for proper web hosting, but it does help cache content at the network edge, which improves website performance. Adding it to your website hosting helps optimize for performance.

\n\n\n\n

The CDN is a layer in your web tech stack that you must account for when you are in the planning phases of adopting Headless WordPress. Doing this ad-hoc and DIY can be time-consuming and tedious for the developer team. In order to alleviate this issue, Atlas does this for you out of the box.

\n\n\n\n

Atlas’s out-of-the-box CDN utilizes caching to reduce hosting bandwidth, helping to prevent interruptions in service, and improving security, and performance. A CDN, by nature, is distributed geographically which reduces the time it takes to get to your users. When you combine this with the approach of the Jamstack/decoupled architecture which prebuilds the markup, all those files become available statically on the CDN.

\n\n\n\n

In summary, the Atlas CDN provides:

\n\n\n\n

Improving website load times
Reduced bandwidth costs
Increased content availability and redundancy
Improved security

\n\n\n\n

WordPress APIs and 3rd Party APIs

\n\n\n\n

The next thing to consider in planning for the development of Headless WordPress is the WordPress install itself. Questions arise such as where to host it, which API you will use (WPGraphQL or REST), plugins, pairing environments with the JS frontend, and any customization to it.

\n\n\n\n

Even though a static Jamstack site can indeed be nothing more than a collection of static assets, connecting your application to your WP backend with the WPGraphQL or REST API is what shows the true power and promise of this as an architecture for real-world applications.

\n\n\n\n

This is the power and foundation behind the modular, decoupled, Jamstack approach. It gives frontend teams the power to not have to write any backend code. They can consume the WordPress data through an API endpoint, mainly REST or GraphQL.

\n\n\n\n

In fact, you’ll find many traditional players like Shopify, SalesForce, BigCommerce, GitHub, etc now offer APIs so they, too, can be consumed in a headless fashion. The explosion of APIs speaks to the momentum of the decoupled movement as the architecture of the interconnected web. As this API-driven development is becoming the norm, Atlas will support it.

\n\n\n\n

Once you decide what API you will use for WordPress, you will need a WordPress host for that install. On Atlas, you have a trusted WP hosting platform fully managed. You can rest assured that your WP install is kept secure, up to date, and given best-in-class maximum uptime as well as provisioning new WP installs with a simple click.

\n\n\n\n

FAQs/Best Practices 🌐 🤓

\n\n\n\n

Q: Can the size of a developer team affect the decisions on the kind of workflow implemented in Headless WordPress? (Large Agency/Small Independent Contractor)

\n\n\n\n

A: This is a subjective question because the size and number of a dev team are relative. However, for this article’s sake, let’s just say there can be a single one-person developer, a small dev team is about 2-5, and anything above 5 is mid to large.

\n\n\n\n

The main thing to consider here is your environments as far as development, staging, and production. If you have a large developer team that is pushing numerous changes to your code, it is a necessity to ensure those changes are exactly what you wanted before going live. Isolating these changes in environments solves this.

\n\n\n\n

A single developer can set up a simplified workflow with maybe only one or two environments, plus local. The Local Sites tool is great for a single developer workflow.

\n\n\n\n

When a development team is small to large, there are three things to consider when planning a workflow – 1) Everyone is able to contribute, 2) Everyone has access to the most recent versions, and 3) All developers are able to iterate through CI/CD.

\n\n\n\n

For larger agency teams, especially when developers are switching between projects, you might want to use a containerized approach where you can create a repeatable/cloned environment that each team member can use.

\n\n\n\n

Q: What if I want an efficient way to check my code on the browser without pushing it to production?

\n\n\n\n

Deployment previews in Atlas allow you to deploy a preview environment on a live URL without having to procure any isolated staging environment. It gives you a unique live site that is isolated off any feature branch you checkout. This will alleviate the issue of spinning up multiple staging environments and make your Atlas workflow better.

\n\n\n\n

Q: What are some recommendations for making sure your front & backend deploy at the same time?

\n\n\n\n

A: There are different ways you can approach the answer to this. For example, if you need to push changes to the WordPress backend to add and or remove functionality, and push changes to the frontend app synchronously to accommodate those backend changes, what is the best way to do so? 🤔

\n\n\n\n

Two main solutions that are most commonly used are:

\n\n\n\n

Push changes for the frontend & backend at the same time and don’t worry about the time variance. This would work for hobby sites, but not important ones where a page in an error state could mean an abandoned shopping cart, etc.
Include fallback code and do it in stages. Push code to the frontend and backend that tries to use the new changes, but gracefully falls back to the old version if it’s not available. This approach could use a feature flag, check for a certain version number, etc. Then once you’re confident all users are on the new version of the frontend application, push another update to finally remove the old functionality.

\n\n\n\n

One thing to note is that there really is no perfect solution to this question or any solution in Headless web development for that matter. The challenge of keeping your different code bases in sync from a timing perspective in this approach will have trade-offs on any option you choose and these are things that come with the territory. The key here is to just figure out which trade-offs mean more to you and your team.

\n\n\n\n

If you want a more granular example of these solutions to this question, we will have a deeper dive into it in an article to come soon!

\n\n\n\n

Let us know your thoughts!

\n\n\n\n

Feedback is golden on a product for developers. If there are any features that you want to see on Atlas and WordPress as a Headless CMS, please let us know! Drop us a line in our discord channel. Stoked!!! 🎉

\n"},{"__typename":"Post","id":"cG9zdDo2NDU=","slug":"atlas-platform-features-deployment-previews-webhooks","seo":{"__typename":"PostTypeSEO","readingTime":8,"opengraphDescription":"In this article, I will discuss the new Preview Environments and Webhook features in the Atlas platform. If you are new to Headless WordPress and would like to start testing out Atlas, sign up for a free sandbox account here! The Modern Developer Workflow Modern web developers using a git-based approach to development expect certain […]"},"title0":"Atlas Platform Features: Deployment Previews & Webhooks","uri":"/atlas-platform-features-deployment-previews-webhooks/","author":{"__typename":"NodeWithAuthorToUserConnectionEdge","node":{"__typename":"User","id":"dXNlcjo3","avatar0":{"__typename":"Avatar","url":"https://secure.gravatar.com/avatar/c24a68b84c9ad2b53c633d14917d8298?s=96&d=mm&r=g"},"name":"Francis Agulto","description":"---\r\ntitle: Developer Advocate\r\n---","seo":{"__typename":"SEOUser","social":{"__typename":"SEOUserSocial","twitter":""}}}},"date":"2022-09-20T15:23:02","content0":"\n

In this article, I will discuss the new Preview Environments and Webhook features in the Atlas platform. If you are new to Headless WordPress and would like to start testing out Atlas, sign up for a free sandbox account here!

\n\n\n\n

The Modern Developer Workflow

\n\n\n\n

Modern web developers using a git-based approach to development expect certain features and functionality on their hosting platforms, especially ones that support their CI/CD (Continuous Integration and Continuous Delivery) workflows.

\n\n\n\n

In the past, hosting platforms only allowed you to deploy sites to the same URL every time you pushed a change. If you wanted to test changes before making them live on your production site, you had to manually create new sites or environments with new URLs to preview those changes.

\n\n\n\n

For example, in some workflows, you may have testing or staging branches tied to specific environments, and committing to those branches could help you automatically preview your changes before merging them into production. While you can still do this with Atlas environments, this Git flow strategy may be too rigid for some teams or conflict with other philosophies on repository management.

\n\n\n\n

Luckily, the Atlas platform has a solution for this issue that makes CI/CD less tedious and more flexible to implement.

\n\n\n\n

Deployment Previews

\n\n\n\n

The Atlas team got me super stoked as we now have deployment previews!! This allows you and your team to see changes on your site without having to deploy them to your production site and without having to create a dedicated testing branch or environment.

\n\n\n\n

The value for the modern developer’s workflow is a less tedious, quicker way to enable better productivity. As a developer, this helps you achieve constant collaboration and iteration for a quicker “ship more and ship fast flow.”

\n\n\n\n

How Deployment Previews Work

\n\n\n\n

Deployment previews work by deploying every pull request from your GitHub repository to a specific preview environment, with its own URL, logging, and tools, in relation to the feature branch you created. This isolates each branch you make from your main production branch without having to manually spin up entirely new site environments!

\n\n\n\n

You and your team can view the unique URL to see how these changes look before they are merged into production and deployed.

\n\n\n\n

In order to enhance the workflow even more you can access information about the Atlas preview environment in two places: the GitHub UI and the Atlas Platform UI:

\n\n\n\n

\n\n\n\n

\n\n\n\n

You can link back and forth between UI’s conveniently as well.

\n\n\n\n

As you iterate and develop your site, you can continuously push multiple changes, checkout multiple branches, and share these URLs for collaboration and feedback, in turn exponentially increasing overall developer and team productivity. Under the hood, Atlas keeps up with your feature branch changes, builds the environment, and provides the unique URL! ⚡

\n\n\n\n

Please visit the preview environment docs for a step-by-step guide on usage.

\n\n\n\n

Deployment Previews FAQs

\n\n\n\n

I Don’t See Deployment Previews Anywhere in the Atlas Platform

\n\n\n\n

The deployment previews feature needs to be enabled on a per-environment basis, which means if you want to preview PRs submitted against your main or production branch, the setting needs to be enabled for that Atlas environment.

\n\n\n\n

Do Deployment Previews Count Towards My Resources?

\n\n\n\n

No, any deployment previews that you create do not count towards your plan entitlements.

\n\n\n\n

What Happens if I Make Additional Commits to a PR?

\n\n\n\n

If you continue to make commits to a feature branch with an open PR, Atlas will detect those changes and rebuild your deployment preview.

\n\n\n\n

How Do I Delete a Deployment Preview?

\n\n\n\n

The main mechanism for managing preview environments is the PR lifecycle. If you close a PR or merge it into its target branch, those actions will automatically delete the deployment preview associated with the PR.

\n\n\n\n

Atlas Environment Rebuild Webhooks

\n\n\n\n

The modern git-based workflow gets me JAMstoked because it enables quick continuous streamlined workflows with all things expected to be connected once things are spun up and pushed into your repository.

\n\n\n\n

Often times though, there are teams of content creators or other technical/non-technical stakeholders who are not immersed in the git-based flow but still need a way to push changes from the WordPress CMS to the front-end of their headless site. For example, if a site is using SSG, a content editor may want to rebuild a particular post or page whenever they update the resource in WordPress.

\n\n\n\n

What is a Webhook?

\n\n\n\n

This is where webhooks come into the workflow. A webhook is an HTTP-based callback function that allows lightweight, event-driven communication between two APIs.

\n\n\n\n

In this case, the WP Engine Atlas platform features webhooks that allow users to trigger an environment rebuild from an event created by WordPress. (e.g. updating, deleting, adding posts)

\n\n\n\n

Configuring Builds with Atlas Webhooks

\n\n\n\n

The Atlas platform makes it really easy to generate a webhook to rebuild your environment via WordPress events.

\n\n\n\n

Step 1: Go into your Atlas account and on to the Atlas accounts home page. Click on any app environment you choose:

\n\n\n\n

\n\n\n\n

Step 2: Once you choose an app environment and click on it, you will be taken to an environment settings page. Click on the Settings link:

\n\n\n\n

\n\n\n\n

Step 3: Clicking on the Settings link takes you to the Settings page. In the lower half of the page, you will see an Environment webhook pane. Click the Create a webhook button:

\n\n\n\n

\n\n\n\n

Once you click that, an endpoint will be generated like this:

\n\n\n\n

\n\n\n\n

Copy that endpoint URL because we are going to need it for our WordPress backend.

\n\n\n\n

Embed the Webhook in WordPress

\n\n\n\n

Now that your webhook is created on the Atlas platform, go into your WP Admin. From here, you can select a plugin that will help trigger your Atlas webhook based on an action you do in WordPress, such as adding a new post for example.

\n\n\n\n

You can use any plugin you like and we have some other suggestions in our docs, but in this example, I will use WP Webhooks.

\n\n\n\n

Go to the side menu of your WP Admin and hit Plugins > Add New and search for WP Webhooks. It should be the first one you see:

\n\n\n\n

\n\n\n\n

Once you install and activate the plugin, it will give you an option on the menu under Settings. Click on WP Webhooks there:

\n\n\n\n

\n\n\n\n

This will bring you to the WP Webhooks main page. In this case, we want to send data via a POST request to the Atlas platform when the webhook is triggered, so click on the Send Data option at the top:

\n\n\n\n

\n\n\n\n

Next, you will have options on what actions you want to associate with your webhook trigger. Let’s use Post updated. Once you choose the action, click on Add Webhook URL:

\n\n\n\n

\n\n\n\n

When you select those options, you will see a modal pop-up that will ask you to name your webhook and embed the webhook you created from Atlas:

\n\n\n\n

\n\n\n\n

And done!!! The next thing to do is go and create a new post. When you hit publish on that post, you can go to your Atlas account in WP Engine and see that a build was triggered due to the action in your WordPress backend!! Stoked! 🎉

\n\n\n\n

This feature here allows the modern web teams the ability to update data without having to touch code or jump into a command line.

\n\n\n\n

Please reference the docs as well for webhooks.

\n\n\n\n

Stay Tuned, more Atlas features to come…

\n\n\n\n

These two features are table stakes that modern jamstack/decoupled hosting platforms should have. The addition of these features to the Atlas platform will improve your modern web dev workflow across all your teams and stakeholders.

\n\n\n\n

Stay tuned for more Atlas features to come! As always let us know your feedback, thoughts, and ideas in Discord!

\n"},{"$ref":"$[\"cache\"][\"posts1\"][\"nodes\"][5]"},{"__typename":"Post","id":"cG9zdDo2NTE=","seo":{"__typename":"PostTypeSEO","readingTime":6,"opengraphDescription":"In this post, we'll look at some of the best headless eCommerce platforms that you can use with your headless WordPress sites."},"uri":"/best-headless-ecommerce-platforms-for-wordpress/","title0":"Best Headless eCommerce Platforms for WordPress","author":{"__typename":"NodeWithAuthorToUserConnectionEdge","node":{"__typename":"User","id":"dXNlcjoxMg==","avatar0":{"__typename":"Avatar","url":"https://secure.gravatar.com/avatar/a64abda82041a00e479ecc2b156d7947?s=96&d=mm&r=g"},"name":"Jeff Everhart","description":"---\r\ntitle: Sr. Developer Advocate\r\n---","seo":{"__typename":"SEOUser","social":{"__typename":"SEOUserSocial","twitter":""}}}},"date":"2022-09-12T14:51:01","content0":"\n

The movement toward headless or decoupled sites involves giving site builders freedom to use the platforms and tools they already have, instead of locking them into an ecosystem that won’t evolve with their development practices. When talking to developers considering switching to a headless eCommerce platform as a solution to specific problems with monolithic or traditional eCommerce sites, here are a few things they mention:

\n\n\n\n

All-in-one eCommerce Platforms Lack Key Features

\n\n\n\n

If you have a traditional eCommerce site, and it doesn’t manage your content marketing collateral effectively, headless eCommerce patterns allow you to integrate other headless CMSs that do a better job of creating and managing content.

\n\n\n\n

API-driven Development of Headless eCommerce Enables Flexibility

\n\n\n\n

If your business or organization has unique requirements, such as offering products for both wholesale and retail or supporting multiple storefronts, it may be easier to support those use cases with the API-driven development patterns that headless eCommerce enables. In addition, API-driven commerce can more easily enable sales in non-standard channels, such as in-game transactions or AR/VR environments.

\n\n\n\n

Headless eCommerce Offers Total Control over the Site Experience

\n\n\n\n

While all-in-one eCommerce solutions can be great for getting a small business up and running quickly, at a certain scale, online sellers may need more control over the site experience than all-in-one platforms can provide. Whether the goal is increased speed, scalability, performance, or improved aesthetics, a headless approach can provide more granular control over these aspects of your eCommerce site. Anecdotally, this is what we see from larger brands and stores that want a higher degree of control than any all-in-one platform can offer.

\n\n\n\n

Choosing a Headless eCommerce Platform

\n\n\n\n

With an increased interest in headless eCommerce, it’s no surprise that both existing and new companies are creating solutions to fill this demand. As a part of our own research into the space, the WP Engine headless developer relations teams spent some time looking at the most popular headless eCommerce platforms. This list isn’t exhaustive, so if you think there is a service missing from this list, please let us know so we can add it to the roundup. We’ll do our best to keep this list updated with the latest features as these platforms grow and evolve.

\n\n\n\n

BigCommerce

\n\n\n\n

BigCommerce provides a variety of eCommerce solutions, and headless eCommerce is one of those features. There is already a Vercel/Next.js integration with BigCommerce. The BigCommerce platform has fairly robust documentation for its REST APIs, and it looks like they are in the process of building new APIs using GraphQL. The platform also offers a service for generating webhooks based on certain events.

\n\n\n\n

Shopify

\n\n\n\n

Shopify is one of the largest players in eCommerce and will likely be the most well-known name on this list. It advertises headless options as a part of its Plus offering and overall has a long reputation of being friendly to developers. Headless commerce is enabled on the platform using a number of different APIs. The Admin API offers features in both REST and GraphQL, while the Storefront API offers developers a GraphQL API that they can use with a number of different SDKs, including Node.js and PHP.

\n\n\n\n

But Shopify also provides a JavaScript-based framework called Hydrogen that provides a lot of out-of-the-box configuration and scaffolding for developers looking to use React. If you’re building apps or integrating with other services, there are webhooks you can tap into as well.

\n\n\n\n

Swell

\n\n\n\n

Swell is an API-first, as opposed to API-only, service for modern eCommerce. The Swell platform provides developers with backend and storefront REST APIs to create both custom administrative back-office experiences as well as custom storefronts. In addition to these headless features, Swell also has a system of events and webhooks that developers can use to run custom business logic based on platform events.

\n\n\n\n

Since Swell is API-first and not API-only, it also provides some of the traditional tools you might expect with other eCommerce platforms, like a visual shop builder and admin interfaces to manage data, but also a hosted checkout page in case developers want to offload this portion of development to the platform. A GraphQL API appears to be in beta.

\n\n\n\n

CommerceLayer

\n\n\n\n

CommerceLayer bills itself as a composable commerce API for developers, and this developer-centric positioning is apparent both on its website and in its onboarding process, which asks you to create inventory and run a test purchase all via CLI commands 🤯

\n\n\n\n

In addition to 400+ REST API endpoints, the platform also offers real-time webhooks and a few dozen integrations with other platforms. While it is positioned primarily as an API tool, it includes hosted checkout pages and carts, as well as an admin interface to manage back-office data.

\n\n\n\n

Commerce.js

\n\n\n\n

Commerce.js is an API-first platform that offers an admin dashboard along with a set of robust commerce APIs, as well as some hosted checkout features. The REST API endpoints have a lot of documentation and a JavaScript SDK to make building applications easier. In addition, Swell has curated some framework-based starter applications that developers can use to get up and running quickly in their favorite framework. The platform also has a list of events that can generate webhooks.

\n\n\n\n

One intriguing feature of Commerce.js is its positioning around alternative methods of payment and varying points of sale, advertising things like payment via Crypto gateway or with a QR code and taking payments inside of video games or from IoT devices. Some of that is likely possible on other commerce platforms, but it is interesting to see it highlighted like this on the Commerce.js platform because it really speaks to where eCommerce is headed.

\n\n\n\n

Snipcart

\n\n\n\n

Snipcart allows you to easily add a shopping cart to an existing website and is built around facilitating commerce using Jamstack approaches to development. It provides a robust suite of tools for sellers and offers a quick and easy JavaScript integration. If you are looking to create commerce functionality in an existing JavaScript application, you can use their JavaScript SDK, but they offer a robust REST API as well if you want to integrate with another backend service or write your own integration with your front-end site. Like many other platforms, Snipcart offers event-based webhooks and has a number of community-supported integrations.

\n\n\n\n

WooCommerce

\n\n\n\n

As a WordPress-focused company, we can’t talk about headless eCommerce without mentioning WooCommerce. WooCommerce is a plugin-based add-on that turns WordPress itself into a commerce engine. For most WooCommerce users, this means WordPress gets used in a traditional or monolithic way, but WooCommerce also enables headless development using both core features and additional plugins. For example, WooCommerce extends WordPress’ REST API, which allows developers to integrate with WooCommerce in a variety of creative ways. If you’re looking to use GraphQL, WPGraphQL has a community-supported add-on for WooCommerce that should enable that. WooCommerce comes with a lot of built-in tools for inventory & commerce management, but also includes a system of webhooks as a part of the API.

\n\n\n\n

Comparison Table

\n\n\n\n

	Management UI	REST API	GraphQL API	Webhooks	Hosted Store Components
BigCommerce	✅	✅	Early Release	✅	✅
Shopify	✅	✅	✅	✅	✅
Swell	✅	✅	Beta	✅	✅
CommerceLayer	✅	✅	❌	✅	✅
Commerce.js	✅	✅	❌	✅	✅
Snipcart	✅	✅	❌	✅	✅
WooCommerce	✅	✅	✅	✅	✅

\n\n\n\n

This table was last updated on 09/12/2022. If you believe something has changed on one of these platforms, please let us know.

\n\n\n\n

Did We Miss Anything?

\n\n\n\n

If you think that we need to add another eCommerce platform to the list, feel free to let us know on Twitter or through our Discord. We are always interested in growing the list of tools we can recommend or hearing about the cool things you’ve been building.

\n\n\n\n

\n","slug":"best-headless-ecommerce-platforms-for-wordpress"},{"__typename":"Post","id":"cG9zdDo2MzM=","slug":"sitemaps-in-headless-wordpress-with-next-js","seo":{"__typename":"PostTypeSEO","readingTime":12,"opengraphDescription":"In this tutorial, you will learn how to create sitemaps in Headless WordPress using Next.js and the WP Sitemap Rest API plugin. (Just a note, if you need a foundational understanding of Next.js, please follow this tutorial by my main man Jeff Everhart. Previously, I wrote about what Sitemaps are and the benefits of them […]"},"title0":"Sitemaps in Headless WordPress with Next.js","uri":"/sitemaps-in-headless-wordpress-with-next-js/","author":{"__typename":"NodeWithAuthorToUserConnectionEdge","node":{"$ref":"$[\"cache\"][\"posts1\"][\"nodes\"][0][\"author\"][\"node\"]"}},"date":"2022-09-09T17:24:29","content0":"\n

In this tutorial, you will learn how to create sitemaps in Headless WordPress using Next.js and the WP Sitemap Rest API plugin. (Just a note, if you need a foundational understanding of Next.js, please follow this tutorial by my main man Jeff Everhart.

\n\n\n\n

Previously, I wrote about what Sitemaps are and the benefits of them in this article you can reference here. In the context of this blog post, we will jump right into creating the sitemaps. By the end of this tutorial you will be able to:

\n\n\n\n

Create a Sitemap in Next.js that dynamically pulls your URLs from WordPress

\n\n\n\n

Add your Next.js pages and paths on your Sitemap including dynamic routes

\n\n\n\n

Setup your WordPress Site

\n\n\n\n

The first thing we are going to do is configure your WordPress site so that we have access to the particular endpoints for our Sitemaps. We are going to use the WP Sitemap Rest API plugin. Download the plugin from the repo via zip file. Next, In WP Admin, go to the Plugins > Add Plugins option at the top right and upload the plugin.

\n\n\n\n

Once you install that plugin, you expose these 4 endpoints to your REST API in WordPress:

\n\n\n\n

/wp-json/sitemap/v1/totalpages\n/wp-json/sitemap/v1/author?pageNo=1&perPage=1000\n/wp-json/sitemap/v1/taxonomy?pageNo=1&perPage=1000&taxonomyType=category or tag\n/wp-json/sitemap/v1/posts?pageNo=1&perPage=1000&postType=post or page

\n\n\n\n

Easily, with this plugin, if you visit “your.wordpresssite.com” plus appending any of the 4 endpoints, you will get an object back of what those paths reflect. An example of my demo site with the first endpoint added:

\n\n\n\n

\n\n\n\n

Easy Peasy, now on to the Next.js frontend.

\n\n\n\n

Install Dependencies

\n\n\n\n

Before we go into the code, we need to install a dependency we will use in this tutorial within our Next.js project called axios. Axios will give us some helper functionality to make XMLHttpRequests from our Next.js front-end. To do this, run npm i axios in your terminal.

\n\n\n\n

Environment Variables

\n\n\n\n

There are a couple of endpoints we will have to set up as environment variables in our project before we create the functions needed.

\n\n\n\n

In the root of your project, create a .env.local file. In this file, add your endpoints and how many items per sitemap you would want. Note that on the frontend URL, because I am using a development environment on my local machine, I am using the Next.js default of localhost with port 3000.

\n\n\n\n

NEXT_PUBLIC_WORDPRESS_API_URL=https://yourwordpresssite.com\nNEXT_PUBLIC_FRONTEND_URL=http://localhost:3000\nNEXT_PUBLIC_ITEM_PER_SITEMAP=50

\n\n\n\n

Now that we have added our environment variables in the properly named file, let’s allow our project access to them via the process.env object.

\n\n\n\n

In the root of your project, create a utils folder. In the utils folder, create a file called variables.js. In this file, add this code block:

\n\n\n\n

export const wordpressUrl = process.env.NEXT_PUBLIC_WORDPRESS_URL;\nexport let frontendUrl = process.env.NEXT_PUBLIC_FRONTEND_URL;\nexport let sitemapPerPage = process.env.NEXT_PUBLIC_ITEM_PER_SITEMAP || 50; //1000

\n\n\n\n

The variables we are naming above are needed so that Next.js can access those endpoints from our .env.local with the process.env object.

\n\n\n\n

Next.js sitemap functions

\n\n\n\n

We are going to need a few functions in order to dynamically grab the total amount of WordPress URLs to make them available to your sitemap index page and show them on the browser as well as showing our Next.js front-end URL’s.

\n\n\n\n

The first step is to create a folder called lib in the root of the project. In the new lib folder, create a file called getTotalCounts.js and add this code block:

\n\n\n\n

import axios from \"axios\";\nimport { wordpressUrl } from \"../utils/variables\";\n\nexport default async function getTotalCounts() {\n  const res = await axios.get(`${wordpressUrl}/wp-json/sitemap/v1/totalpages`);\n  let data = await res.data;\n  if (!data) return [];\n  const propertyNames = Object.keys(data);\n  let excludeItems = [\"user\"];\n  //if you want to remove any item from sitemap, add it to excludeItems array\n  let totalArray = propertyNames\n    .filter((name) => !excludeItems.includes(name))\n    .map((name) => {\n      return { name, total: data[name] };\n    });\n\n  return totalArray;\n}

\n\n\n\n

This file is a fetch function that is grabbing the total pages from your WordPress site and returning that data in an array. If you want to exclude any data from your sitemap you can add it to the excludeItems array as commented.

\n\n\n\n

The next thing we need to create is a way to get the sitemap pages and return them for the specific type.

\n\n\n\n

Back in our utils folder, create a file called getSitemapPages.js and add this code block:

\n\n\n\n

import { frontendUrl, sitemapPerPage } from \"./variables\";\n\nexport default function getSitemapPages(item) {\n  const items = [];\n  for (let i = 1; i <= Math.ceil(item.total / sitemapPerPage); i++) {\n    let url = `${frontendUrl}/sitemap/${item.name}_sitemap${i}.xml`;\n    items.push(\n      ` \n        <sitemap>\n           <loc>\n              ${url}\n          </loc>\n      </sitemap>\n      `\n    );\n  }\n  return items.join(\"\");\n}

\n\n\n\n

This file is importing the variables we declared in our variables.js file. Then, it exports a function by default that is passing in the item from the total counts function we created. Once these are passed in, the front-end URL is appended with the item name and the XML path. Then we join these with the XML tags with the slug from WordPress.

\n\n\n\n

We now have the necessary functions in place to generate our sitemap pages and the total number of them. The next step is to create a sitemap index page.

\n\n\n\n

Sitemap Index Page

\n\n\n\n

We are going to take advantage of Next.js and its page-based file routing. This means that any file I add to the pages directory in my project will correspond automatically to a route that is available.

\n\n\n\n

Create a file in the pages directory of your project called sitemap.xml.js and add this code block:

\n\n\n\n

import getSitemapPages from \"../utils/getSitemapPages\";\nimport getTotalCounts from \"../lib/getTotalCounts\";\nexport default function SitemapIndexPage() {\n  return null;\n}\nexport async function getServerSideProps({ res }) {\n  const details = await getTotalCounts();\n\n  let sitemapIndex = `<?xml version='1.0' encoding='UTF-8'?>\n  <sitemapindex xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n           xsi:schemaLocation=\"http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/siteindex.xsd\"\n           xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\">\n     ${details.map((item) => getSitemapPages(item)).join(\"\")}\n  </sitemapindex>`;\n  res.setHeader(\"Content-Type\", \"text/xml; charset=utf-8\");\n  res.setHeader(\n    \"Cache-Control\",\n    \"public, s-maxage=600, stale-while-revalidate=600\"\n  );\n  res.write(sitemapIndex);\n  res.end();\n  return { props: {} };\n}\n

\n\n\n\n

The first thing to notice at the top of the file is the importing of the two functions we just created to generate the WordPress page types and the total counts. Then we have this page as a default function that will utilize server-side rendering since we want this page to be dynamic on every request so the sitemap is up to date.

\n\n\n\n

Next, I copied a sitemap example and formatted it so that the XML tags and links show up on the browser with the response header set and the page write response set to load and end with the props returned.

\n\n\n\n

Let’s get stoked now and see what this looks like on the browser. Go to your terminal and run npm run dev. You should see this:

\n\n\n\n

\n\n\n\n

Awesome!! We now have a dynamic sitemap in a headless WordPress setup. The next step is to add the ability to grab the URL of the sitemap path and have that route to its detail page.

\n\n\n\n

Dynamic Sitemap Page Routes

\n\n\n\n

We need a couple of things to make the dynamic page routes work for our sitemap. First, we need a way to generate the sitemap paths to their detail page.

\n\n\n\n

Go back to the utils folder we created earlier. In this folder, create a generateSitemapPaths.js file and add this code block:

\n\n\n\n

import { frontendUrl } from \"./variables\";\n\nexport default function generateSitemapPaths(array) {\n  const items = array.map(\n    (item) =>\n      `\n            <url>\n                <loc>${frontendUrl + item?.url}</loc>\n                ${\n                  item?.post_modified_date\n                    ? `<lastmod>${\n                        new Date(item?.post_modified_date)\n                          .toISOString()\n                          .split(\"T\")[0]\n                      }</lastmod>`\n                    : \"\"\n                }\n            </url>\n            `\n  );\n  return items.join(\"\");\n}

\n\n\n\n

This file imports our front-end URL variable and then exports a default function that passes in an array. The items variable is mapped which then returns a single item. Then we have XML tags that dynamically grab the appropriate item and concatenate that to your frontend URL, as well as the date the page was last modified. Now that we have the function needed, let’s create the dynamic route page.

\n\n\n\n

Next.js makes it easy to create a dynamic file if you have a parameter like a slug that changes upon request. The naming convention for this is the bracket syntax. Create a folder in the pages directory called sitemap. In this folder, create a file called [slug].js:

\n\n\n\n

\n\n\n\n

In the [slug].js file, add this code block:

\n\n\n\n

import getSitemapPageUrls from \"../../lib/getSitemapPageUrls\";\nimport getTotalCounts from \"../../lib/getTotalCounts\";\nimport generateSitemapPaths from \"../../utils/generateSitemapPaths\";\nexport default function SitemapTagPage() {\n  return null;\n}\nexport async function getServerSideProps({ res, params: { slug } }) {\n  let isXml = slug.endsWith(\".xml\");\n  if (!isXml) {\n    return {\n      notFound: true,\n    };\n  }\n  let slugArray = slug.replace(\".xml\", \"\").split(\"_\");\n  let type = slugArray[0];\n  let pageNo = slugArray[1]?.match(/(\\d+)/)[0] ?? null;\n  let page = pageNo ? parseInt(pageNo) : null;\n  let possibleTypes = await getTotalCounts();\n  if (!possibleTypes.some((e) => e.name === type)) {\n    return {\n      notFound: true,\n    };\n  }\n  let pageUrls = await getSitemapPageUrls({ type, page });\n  if (!pageUrls?.length) {\n    return {\n      notFound: true,\n    };\n  }\n  let sitemap = `<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n  <urlset xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd\"\n  xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\">\n    ${generateSitemapPaths(pageUrls)}\n  </urlset>`;\n  res.setHeader(\"Content-Type\", \"text/xml; charset=utf-8\");\n  res.setHeader(\n    \"Cache-Control\",\n    \"public, s-maxage=600, stale-while-revalidate=600\"\n  );\n  res.write(sitemap);\n  res.end();\n  return { props: {} };\n}

\n\n\n\n

There is quite a bit of code in this file. Essentially, what is happening in this file is that we are importing all of our functions at the top that we need access to for the sitemap dynamic paths.

\n\n\n\n

Next, a default function is exported, calling it SitemapTagPage. We return null, then have an async function to getServerSideProps as we want this function to be server-side rendered as well on every request. Then in the response object, we pass in the params which is the slug in this case.

\n\n\n\n

Our variable isXML is equal to the slug and the appended XML path ending. If this a not an xml slug and path we return it to not be found.

\n\n\n\n

In the middle of the file, we declare numerous variables that we name as we need to set the array of slugs, the type, the page number using regex which extracts the number from the string, and the possible types and the total counts of those types.

\n\n\n\n

Lastly, we validate this to see if it properly is aligned with our sitemap index page, otherwise, we throw a 404. Once that is done, we have our XML tags formatted and the appropriate responses.

\n\n\n\n

Let’s try this now and see if this works in the browser. Go back to the terminal and run npm run dev. Once the sitemap index page shows on the browser, grab any URL on the sitemap and put it in the search bar:

\n\n\n\n

\n\n\n\n

I chose to grab my post page URL at sitemap/post_sitemap1.xml. I followed that link in the search bar and got the post sitemap details! Stoked!! 🎉

\n\n\n\n

Next.js Pages

\n\n\n\n

Finally, we need to account for our Next.js pages on our front-end. In order to do this, let’s go to our pages directory and add a file called sitemapnextjs.xml.js. In this file, add this code block:

\n\n\n\n

import React from \"react\";\nimport * as fs from \"fs\";\nconst Sitemap = () => {\n  return null;\n};\n\nexport const getServerSideProps = async ({ res }) => {\n  const BASE_URL = \"http://localhost:3000\";\n\n  const staticPaths = fs\n    .readdirSync(\"pages\")\n    .filter((staticPage) => {\n      return ![\n        \"api\",\n        \"about\",\n        \"_app.js\",\n        \"_document.js\",\n        \"404.js\",\n        \"sitemap.xml.js\",\n      ].includes(staticPage);\n    })\n    .map((staticPagePath) => {\n      return `${BASE_URL}/${staticPagePath}`;\n    });\n\n  const dynamicPaths = [`${BASE_URL}/name/1`, `${BASE_URL}/name/2`];\n\n  const allPaths = [...staticPaths, ...dynamicPaths];\n\n  const sitemap = `<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n    <urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\">\n      ${allPaths\n        .map((url) => {\n          return `\n            <url>\n              <loc>${url}</loc>\n              <lastmod>${new Date().toISOString()}</lastmod>\n              <changefreq>monthly</changefreq>\n              <priority>1.0</priority>\n            </url>\n          `;\n        })\n        .join(\"\")}\n    </urlset>\n  `;\n\n  res.setHeader(\"Content-Type\", \"text/xml\");\n  res.write(sitemap);\n  res.end();\n\n  return {\n    props: {},\n  };\n};\n\nexport default Sitemap;

\n\n\n\n

At the top of the file, we are importing React, and fs to access local storage. Next, we return null as we want this to not render or return anything in the component. Instead, we will use the getServerSideProps function, export it as a const, then pass in the response object, just like we did in the sitemap index page to server-side render for fresh, up-to-date sitemap data.

\n\n\n\n

Then we declare our base URL variable, in this case, I am using the dev server off localhost:3000.

\n\n\n\n

Once we set the fs to our static paths, we enable a way within the object to filter through our static pages in Next.js within an array and input which ones we do not want on the sitemap. I just added the default pages Next.js comes with as an example.

\n\n\n\n

The next step is to account for the dynamic paths that you have in Next.js, apart from WordPress. We set a const for our dynamic paths and make it equal to an array where we get our base URL and our hard coded path. (I just named it “name” but you can name it in relation to whatever your dynamic route file is)

\n\n\n\n

The last things we need to do are to set the const for all our paths and iterate through them with the spread operator and expand all of them in an array.

\n\n\n\n

Finally, we generate the sitemap in XML format with the appropriate response headers returning our props. Jamstoked!! We now have all the paths and the URLS in our Next.js front-end!!! 💥

\n\n\n\n

Combining Next.js pages and WordPress pages in your sitemap index page

\n\n\n\n

All that is left is adding our Next.js pages to our sitemap index with our WordPress pages. Go back to the sitemap.xml.js file and add this code block:

\n\n\n\n

import getSitemapPages from \"../utils/getSitemapPages\";\nimport getTotalCounts from \"../lib/getTotalCounts\";\nexport default function SitemapIndexPage() {\n  return null;\n}\nexport async function getServerSideProps({ res }) {\n  const details = await getTotalCounts();\n\n  let sitemapIndex = `<?xml version='1.0' encoding='UTF-8'?>\n  <sitemapindex xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n           xsi:schemaLocation=\"http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/siteindex.xsd\"\n           xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\">\n     ${details.map((item) => getSitemapPages(item)).join(\"\")}\n     <sitemap>\n     <loc>\n        http://localhost:3000/sitemapnextjs.xml\n    </loc>\n</sitemap>\n  </sitemapindex>`;\n  res.setHeader(\"Content-Type\", \"text/xml; charset=utf-8\");\n  res.setHeader(\n    \"Cache-Control\",\n    \"public, s-maxage=600, stale-while-revalidate=600\"\n  );\n  res.write(sitemapIndex);\n  res.end();\n  return { props: {} };\n}\n

\n\n\n\n

The one difference in this file is the URL we added http://localhost:3000/sitemapnextjs.xml in our XML element <loc></loc>. This will allow us to show the Next.js pages on our sitemap index.

\n\n\n\n

Let’s see this in action in the browser. Go back to terminal and run npm run dev. You should see this in the browser:

\n\n\n\n

\n\n\n\n

We now have our sitemap for Next.js pages on our index. Let’s see what all the details of our pages are in Next.js when we follow that URL:

\n\n\n\n

\n\n\n\n

Done!! Jamstoked! 🎉

\n\n\n\n

We are finished with this walk-through tutorial! Jamstoke! With this tutorial, we hope you take away the ability to understand the importance of sitemaps and the value of utilizing them to inform search engines of your site’s page and path layout.

\n\n\n\n

This is just one way of approaching sitemaps in headless WordPress. I would love to hear your thoughts and your own approaches and builds. Hit me up in our Discord!

\n\n\n\n

Here is the demo once again so you can follow along, make it your own and add on to it if you like on my GitHub.

\n\n\n\n

I want to give a major shoutout and credit to Dipankar Maikap who created the WP Sitemap Rest Api plugin and assisted me in the creation of this tutorial.

\n"}],"pageInfo":{"__typename":"WPPageInfo","hasNextPage":true,"endCursor":"YXJyYXljb25uZWN0aW9uOjYzMw=="}}},"selections":[[["0-1-2","post0"],["3-4-5","title0"],["6-4-7","avatar0"],["8-4-5","content0"],["9-10-11","youtubeVideos0"],["12-10-13","posts0"],["0-14-2","post1"],["0-15-2","post2"],["0-16-2","post3"],["0-17-2","post4"],["0-18-2","post5"],["0-19-2","post6"],["0-20-2","post7"],["9-21-11","youtubeVideos1"],["0-22-2","post8"],["0-23-2","post9"],["0-24-2","post10"],["0-25-2","post11"],["0-26-2","post12"],["0-27-2","post13"],["0-28-2","post14"],["29-30-31","headlessWordPressPlugins0"],["12-32-13","posts1"],["0-33-2","post15"],["0-34-2","post16"],["0-35-2","post17"],["0-36-2","post18"],["0-37-2","post19"],["0-38-2","post20"],["0-39-2","post21"],["0-40-2","post22"],["0-41-2","post23"],["0-42-2","post24"],["0-43-2","post25"],["9-44-11","youtubeVideos2"],["0-45-2","post26"],["0-46-2","post27"],["0-47-2","post28"],["0-48-2","post29"],["9-49-11","youtubeVideos3"],["0-50-2","post30"],["0-51-2","post31"],["0-52-2","post32"],["0-53-2","post33"],["0-54-2","post34"],["9-55-11","youtubeVideos4"],["0-56-2","post35"],["0-57-2","post36"],["0-58-2","post37"],["0-59-2","post38"],["0-60-2","post39"],["0-61-2","post40"],["0-62-2","post41"],["0-63-2","post42"],["9-64-11","youtubeVideos5"],["0-65-2","post43"],["9-66-11","youtubeVideos6"],["0-67-2","post44"]],[["post",0],["{\"id\":\"introduction-to-graphql-in-wordpress\",\"idType\":\"SLUG\"}",1],["{\"id\":\"ID!\",\"idType\":\"PostIdType\",\"asPreview\":\"Boolean\"}",2],["title",3],["{}",4],["{\"format\":\"PostObjectFieldFormatEnum\"}",5],["avatar",6],["{\"size\":\"Int\",\"forceDefault\":\"Boolean\",\"rating\":\"AvatarRatingEnum\"}",7],["content",8],["youtubeVideos",9],["{\"first\":3}",10],["{\"first\":\"Int\",\"last\":\"Int\",\"after\":\"String\",\"before\":\"String\",\"where\":\"RootQueryToYoutubeVideoConnectionWhereArgs\"}",11],["posts",12],["{\"first\":\"Int\",\"last\":\"Int\",\"after\":\"String\",\"before\":\"String\",\"where\":\"RootQueryToPostConnectionWhereArgs\"}",13],["{\"id\":\"crash-course-build-a-simple-headless-wordpress-app-with-next-js-wpgraphql\",\"idType\":\"SLUG\"}",14],["{\"id\":\"build-a-simple-headless-wordpress-app-with-react-wpgraphql\",\"idType\":\"SLUG\"}",15],["{\"id\":\"gutenberg-in-headless-wordpress-wpgraphql-gutenberg\",\"idType\":\"SLUG\"}",16],["{\"id\":\"atlas-content-modeler-walk-through\",\"idType\":\"SLUG\"}",17],["{\"id\":\"headless-wordpress-authentication-native-cookies\",\"idType\":\"SLUG\"}",18],["{\"id\":\"building-a-headless-wordpress-site-with-astro\",\"idType\":\"SLUG\"}",19],["{\"id\":\"best-headless-ecommerce-platforms-for-wordpress\",\"idType\":\"SLUG\"}",20],["{\"first\":12}",21],["{\"id\":\"what-is-atlas-content-modeler\",\"idType\":\"SLUG\"}",22],["{\"id\":\"headless-wordpress-with-vue-and-nuxt-js\",\"idType\":\"SLUG\"}",23],["{\"id\":\"rendering-patterns-in-headless-wordpress\",\"idType\":\"SLUG\"}",24],["{\"id\":\"crash-course-build-a-headless-wordpress-app-with-faust-and-atlas-content-modeler\",\"idType\":\"SLUG\"}",25],["{\"id\":\"gutenberg-in-headless-wordpress-render-blocks-as-html\",\"idType\":\"SLUG\"}",26],["{\"id\":\"wpgraphql-smart-cache-with-next-js-and-apollo\",\"idType\":\"SLUG\"}",27],["{\"id\":\"atlas-search-facets-and-stemming\",\"idType\":\"SLUG\"}",28],["headlessWordPressPlugins",29],["{\"first\":500}",30],["{\"first\":\"Int\",\"last\":\"Int\",\"after\":\"String\",\"before\":\"String\",\"where\":\"RootQueryToHeadlessWordPressPluginConnectionWhereArgs\"}",31],["{\"first\":9}",32],["{\"id\":\"efficient-ssg-in-next-js-with-wpgraphql\",\"idType\":\"SLUG\"}",33],["{\"id\":\"previews-in-headless-wordpress-using-nextjs\",\"idType\":\"SLUG\"}",34],["{\"id\":\"when-should-i-use-headless-wordpress\",\"idType\":\"SLUG\"}",35],["{\"id\":\"headless-wordpress-with-remix-and-tailwind-css\",\"idType\":\"SLUG\"}",36],["{\"id\":\"custom-content-types-in-headless-wordpress\",\"idType\":\"SLUG\"}",37],["{\"id\":\"set-up-wordpress-as-a-headless-cms\",\"idType\":\"SLUG\"}",38],["{\"id\":\"gravity-forms-in-headless-wordpress-gatsby\",\"idType\":\"SLUG\"}",39],["{\"id\":\"apollo-client-cache-rehydration-in-next-js\",\"idType\":\"SLUG\"}",40],["{\"id\":\"planning-for-headless-wordpress-and-atlas\",\"idType\":\"SLUG\"}",41],["{\"id\":\"work-with-gravity-forms-in-headless-wordpress\",\"idType\":\"SLUG\"}",42],["{\"id\":\"what-is-atlas-search\",\"idType\":\"SLUG\"}",43],["{\"first\":12,\"after\":\"YXJyYXljb25uZWN0aW9uOjMzMQ==\"}",44],["{\"id\":\"catching-the-cache-using-the-apollo-client-and-next-js-on-atlas\",\"idType\":\"SLUG\"}",45],["{\"id\":\"what-is-headless\",\"idType\":\"SLUG\"}",46],["{\"id\":\"what-is-headless-wordpress\",\"idType\":\"SLUG\"}",47],["{\"id\":\"atlas-platform-features-deployment-previews-webhooks\",\"idType\":\"SLUG\"}",48],["{\"first\":12,\"after\":\"undefined\"}",49],["{\"id\":\"seo-in-headless-wordpress-with-yoast-next-js-and-wpgraphql\",\"idType\":\"SLUG\"}",50],["{\"id\":\"sitemaps-in-headless-wordpress-with-next-js\",\"idType\":\"SLUG\"}",51],["{\"id\":\"multilingual-headlesswordpress-with-nextjs-wpgraphql-polylang\",\"idType\":\"SLUG\"}",52],["{\"id\":\"headless-wordpress-tech-stack-options\",\"idType\":\"SLUG\"}",53],["{\"id\":\"introducing-the-headless-wordpress-developer-roadmap\",\"idType\":\"SLUG\"}",54],["{\"first\":12,\"after\":\"YXJyYXljb25uZWN0aW9uOjMyOQ==\"}",55],["{\"id\":\"sitemaps-in-headless-wordpress-with-faust-js\",\"idType\":\"SLUG\"}",56],["{\"id\":\"the-when-and-where-of-rendering\",\"idType\":\"SLUG\"}",57],["{\"id\":\"multi-lingual-headless-wordpress-with-next-js-and-wpgraphql-with-the-polylang-plugin\",\"idType\":\"SLUG\"}",58],["{\"id\":\"introduction-to-the-wordpress-rest-api\",\"idType\":\"SLUG\"}",59],["{\"id\":\"privacy-policy\",\"idType\":\"SLUG\"}",60],["{\"id\":\"graphql-code-generator-for-wpgraphql\",\"idType\":\"SLUG\"}",61],["{\"id\":\"state-of-headless-development\",\"idType\":\"SLUG\"}",62],["{\"id\":\"cHJldmlld3\",\"idType\":\"SLUG\"}",63],["{\"first\":12,\"after\":\"YXJyYXljb25uZWN0aW9uOjI1MQ==\"}",64],["{\"id\":\"building-an-e-commerce-site-using-shopify-headless-wordpress-nextjs-and-chakra-ui-part-1-setup\",\"idType\":\"SLUG\"}",65],["{\"first\":12,\"after\":\"YXJyYXljb25uZWN0aW9uOjI5MA==\"}",66],["{\"id\":\"working-with-gravity-forms-in-headless-wordpress\",\"idType\":\"SLUG\"}",67]],[[0,44],[3,0],[6,0],[8,0],[9,6],[12,1],[29,0]],"v0"]}

Blog