WordPress is going through some fantastic changes right now. Over the past few years, we are seeing a move to a better editing experience with the block editor, aka Gutenberg. An improvement in development experience on the PHP side, and after the REST API landed in the core of the most-used CMS, it opened several doors for the growing headless space, where several sites and companies are using WordPress as a CMS but delivering it via a fast and interactive front-end.
Much of the praise and success GraphQL represents is because of its new ideology when it comes to consuming APIs. Hitherto, using the REST API, anyone that needed to fetch information would usually get more than they needed. Instead, with GraphQL, clients and consumers are able to declaratively fetch only the information they need for the page or request, which has had big ramifications on how developers code and approach projects.
So for this brief article on the matter, I’d like to make a case why GraphQL and WordPress fit well together, how you can use it today with WordPress, and how this technology will increase velocity and improve productivity.
So first, let’s see how you can add it to your WordPress stack right now.
Using GraphQL with WordPress
It took a great deal of effort and time to get the REST API into WordPress core, and I assure you it will take even more to have GraphQL support into it as well. But it is possible to use it today, thanks to plugins available.
One of the leading WordPress plugins in the ecosystem is WPGraphQL. It provides a GraphQL API schema with WordPress data types. Meaning that you can query posts (post types), pages, comments, authors, categories (taxonomies), settings, etc, via its API.
The plugin has many other extensions for WooCommerce, BuddyPress (which I am the creator of), and other known plugins like Yoast SEO. And it is an easy plug-and-play plugin that quickly allows your team to have access to your WordPress information via GraphQL in their front end or apps.
Now, let’s see where GraphQL stands in the APLM process/workflow.
GraphQL and APLM
In the Gartner Top Strategic Technology Trends for 2021 report, Gartner outlines several trend strategies for this year. Some of those trends include AI Engineering, Automation, etc. Almost all the trends and strategies will certainly rely heavily on APIs to better share information/data and insights. Since GraphQL is improving the APLM (API Lifecycle Management) space, there is a lot to be gained in using it. Let’s take a brief look at the APLM phases and how GraphQL is improving them.
There are many benefits to using the REST API, but a few of its problems are the “strictness” of its fields, or shape/schema, provided. The promise of getting all the data in the exact shape one needs in a single request is too hard to resist.
Meaning that, with GraphQL, if you need a new field, there is no need to go to a fresh code iteration in the back end. You only need to establish the scope of data from the schema, and they will be exposed and be readily available to you.
This is another area where a lot can be gained since to author a GraphQL API, you only need a one-time effort. Of course, you can add new fields and types later, but if, for example, you are building a news site and you need to create a columnists page, you don’t need to build another REST API endpoint for that. Your GraphQL API schema would already provide that for you.
Another advantage of using GraphQL is its ease of integration with multiple data sources. Meaning that your API can return information from your, possibly, several databases and APIs (including legacy REST APIs).
There are also other technical benefits, such as API/Schema discovery, IDE support, and tools that the GraphQL ecosystem provides.
Retiring / Deprecating
Another stark difference between REST API and GraphQL comes when needing to retire APIs or endpoint information. In REST, API versioning is the current standard. You create v1, v2, v3, etc., even if you need to make drastic changes, including deprecating it.
Also, tracking API usage is hard with REST. We can’t know for sure when attributes and fields are being used and how much. That’s different with GraphQL. Since it has its typed schema, tracking usage is possible and much easier, including deprecated fields and attributes. You don’t need to change endpoints to accomplish that, and even deprecated information can keep working as long as needed while the front end is being migrated to the new fields/attributes.
GraphQL is not a substitute for REST per se. There are some cons that you should understand before migrating completely into it.
A few of those are:
- There is a steep learning curve in the early days, especially if your developers are not well-versed with it. So migrating completely to GraphQL without understanding its risks can be challenging.
- There are some rough edges, like caching.
- Access control: especially field control, is possible but not as easy as one might think.
Just bear in mind that you might find some hiccups in the process, especially if you are not well-versed in it.
Increasing Velocity and Improving Productivity
When used with WordPress, GraphQL opens up a huge amount of new options and potential. By limiting the amount of code that needs to be updated when an API changes and by providing only what a developer — and an application — needs, you can save time when creating your application and make it much easier for others to understand. Overall, we expect that GraphQL will allow many to create more exciting and useful pieces in less time as it gets further adopted into the WordPress ecosystem.
What questions do you have about GraphQL? What projects are you thinking it might help you create? Maybe we can help! Reach out to us on Twitter.
Interested in learning more about headless? Check out our free webinar on decoupled WordPress – Choose your own adventure : an overview of decoupled solutions in WordPress. – from Christina Deemer and James Burke.