{"id":5315,"date":"2023-06-14T08:27:14","date_gmt":"2023-06-14T14:27:14","guid":{"rendered":"https:\/\/wpengine.com\/builders\/?p=5315"},"modified":"2023-07-14T08:34:06","modified_gmt":"2023-07-14T13:34:06","slug":"moving-get-post-requests-faust-js-1-0-wpgraphql","status":"publish","type":"post","link":"https:\/\/wpengine.com\/builders\/moving-get-post-requests-faust-js-1-0-wpgraphql\/","title":{"rendered":"Moving to GET from POST Requests with Faust.js 1.0 & WPGraphQL"},"content":{"rendered":"\n

As WP Engine approaches two years of offering solutions for headless WordPress on the Atlas Platform<\/a> and Faust.js<\/a> nears its 1.0 launch, we’ve had a lot of time to reflect and learn about the best practices needed to deliver headless WordPress solutions at scale. In this post, we’ll talk about one of those best practices, explore why it’s relevant, and talk about how we’re solving this for you on a foundational level so you can forget about this and go back to writing your site or app.<\/p>\n\n\n\n

Understanding WordPress as a GraphQL API<\/h2>\n\n\n\n

While headless WordPress is becoming more widely used, it still represents a small fraction of total WordPress installs, and we work with people implementing headless WordPress across the spectrum of hosting providers. Because headless WordPress isn’t the default use case for many hosts, we need to think about how we structure our applications and tools to accommodate a wide variation in performance.<\/p>\n\n\n\n

The largest bottleneck we typically see is around data fetching from the GraphQL API, particularly when you are building or prerendering a lot of pages all at once<\/a>. I’ve personally seen examples where a Netlify build process was sending 300 requests per second to build a medium-sized website. \ud83d\ude2e For many shared WordPress hosts, that is easily enough load to start causing timeouts, which lead to failed builds or a 5XX<\/code> error of some kind. With Atlas, we smartly scope your build cores to what your backend can support (since we know about both parts of your app), but that only solves part of the issue, and only on our platform \ud83d\ude09. <\/p>\n\n\n\n

What if your site or application makes lots of simultaneous data requests in a hybrid rendering mode after build time? Or what if many of your pages can’t or shouldn’t be built statically because you need fresh data, like a newsroom or publication?<\/p>\n\n\n\n

Making GraphQL Data More Cachable<\/h2>\n\n\n\n

Traditional WordPress hosting relies on full-page caching to both accelerate site resources and limit the load on shared infrastructure. For most hosts, WP Engine included, GET requests to the REST API are cached as well, typically along the same guidelines as a regular page cache: 600 seconds.<\/p>\n\n\n\n

But most headless WordPress examples and starter projects, especially those using WPGraphQL, don’t take advantage of any caching layer because they use POST requests instead of GET requests. <\/p>\n\n\n\n

In traditional HTTP-based systems, like REST APIs for example, request methods<\/a> are almost like verbs, performing a certain action against a system. GET requests<\/a> are typically used to retrieve data from an external system and are usually considered cachable requests. <\/p>\n\n\n\n

POST requests<\/a>, on the other hand, are requests that send data to the server, and these requests, because they often create resources, can cause side effects on the server. For this reason, POST requests bypass most network caching layers and generate a fresh response every time, even when the actual request is only retrieving data. <\/p>\n\n\n\n

The POST Method as Convention<\/h3>\n\n\n\n

Part of this comes down to convention in how developers use GraphQL, with a POST request being the most common method for sending requests to a \/graphql<\/code> endpoint. Even Apollo Client’s default fetch method is POST, for example.<\/p>\n\n\n\n

POST requests to a GraphQL server typically result in a JSON-encoded object that looks like this as the request body:<\/p>\n\n\n

{\n<\/span><\/span>  \"query\"<\/span>: \"...\"<\/span>,\n<\/span><\/span>  \"operationName\"<\/span>: \"...\"<\/span>,\n<\/span><\/span>  \"variables\"<\/span>: { \"myVariable\"<\/span>: \"someValue\"<\/span>, ... }\n<\/span><\/span>}\n<\/span><\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
But most GraphQL servers, WPGraphQL included, can also support GET requests without any additional configuration. The request values, like query<\/code>, operationName<\/code>, and any variables<\/code>, just need to be encoded in a different manner. Instead of sending the details of our query in the request body as JSON, they can be encoded in query parameters like many other GET requests.<\/p>\n\n\n\n
Switching to GET Requests<\/h3>\n\n\n\n
In looking at this example taken from the GraphQL docs<\/a>, the following query   results in a URL like the one below:<\/p>\n\n\n
{\n<\/span><\/span>  me {\n<\/span><\/span>    name\n<\/span><\/span>  }\n<\/span><\/span>}\n<\/span><\/span>\n<\/span><\/span>http<\/span>:\/\/myapi\/graphql?query={me{name}}<\/span>\n<\/span><\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
A Change in Recommended Practice<\/h3>\n\n\n\n
After working with loads of developers and site builders across a number of platforms, the Faust.js and WPGraphQL teams felt like it was time to change the recommended practice to using GET requests by default, and you’ll see that change implemented as a new default in Faust.js soon.<\/p>\n\n\n\n
We also strongly recommend that you explore WPGraphQL Smart Cache<\/a>. Even if you decide not to use GET requests, WPGraphQL Smart Cache will accelerate your post requests using an object cache<\/a>, providing you with some performance benefits.<\/p>\n\n\n\n
With that in mind, there are a few limitations to GET requests that should be called out.<\/p>\n\n\n\n
Limitation 1: Query URI Can Be Too Long<\/h4>\n\n\n\n
Since a GET request contains your entire GraphQL query and variables, if it’s rather complex, it may bump into a server character limit. You can see an example of that here in this GitHub issue noting an error code Request-URI Too Long<\/a>. For most sites, you should be fine, but if you have long queries and need to use GET requests, then the persisted queries feature of WP GraphQL Smart Cache<\/a> should help you out.<\/p>\n\n\n\n
Per the docs: <\/p>\n\n\n\n
\n
In the GraphQL ecosystem, the term \u201cPersisted Queries\u201d refers to the idea that a GraphQL Query Document can be \u201cpersisted\u201d on the server, and can be referenced via a Query ID.<\/p>\n\n\n\n
There are several advantages to using Persisted Queries:<\/p>\n\n\n\n
And for the developer, switching to GET requests by default using an Apollo HTTP Link<\/code> is as simple as switching the useGETForQueries<\/code> option to true<\/code>. The Apollo client<\/a> will then handle constructing your query’s URL for you. In doing this, you can take advantage of any network caching your host may have applied to this path, which should speed up your sites and make them more resilient. In this case, Apollo only uses GET for queries and will continue to use POST for mutations.<\/p>\n\n\n\n