In r/ProWordPress, OP asked a few questions around Headless WordPress in 2023. One question stood out the most:
Developers who develop headless WordPress sites, how are things going in 2023?
Given all that’s happened within the core WordPress application over the last few years – that is, with the Block Editor and Full Site Editing – it’s not only easy to lose sight this is functionality built into WordPress but there’s likely a portion of people onboarded into WordPress development who do almost nothing with this type of work.
Even with all of the excitement around the new editing tools and how much JavaScript has been introduced into WordPress core, building headless applications with WordPress is still something I find to be one of the most powerful aspects of working with the application.
Headless WordPress Applications in 2023
When it comes to building headless applications with WordPress, I tend to think of it in the following abstract ways:
- The Front-end
- The API
- The Processor
- The Data Store
In the various headless solutions I’ve built, almost all of them can be reduced to the above structure and each component will reside in one of the four areas. I’ve worked on software that works with large scale newsrooms to mobile applications.
Using the latter as an example, here’s an example of how a headless application may look:
1. The Front-end
Specifically, I’m using an iOS application as an example. Obviously, there’s functionality that will reside on the device but if it’s going to be sending data to a centralized headless WordPress installation, then it’s going to have to be able to at least write data to it (but read data as well).
In some cases, authentication will be required, in some cases, it won’t. How this is done is topic for another post. Point being, the front-end can be an mobile application.
2. The API
I’ve never written much in the way of API design. Many developers, at this point in their career, know that documentation – perhaps above all else – can make or break how easy it is to work with a given API.
Though I’m not someone who claims to be great at API design, I’ve worked with enough bad APIs to know what I don’t want to do and enough with what I do want to do. Since WordPress allows us to write our own endpoints, we can set out from the project outset how we want the front-end to communicate with WordPress and then build the API around that.
And to that end, in the headless application I’m using as an example, the API deals with user authorization and authentication, reading and writing basic data to the usermeta table, and then allowing the user to view it on the phone and an administrator to see it on a device such as a laptop or iPad.
3. The Processor
I almost wrote this part as “3. WordPress” but I’ve worked with a handful of other headless applications that have some type of content pipeline or pre-processor that will consume information before handing it off to WordPress.
It may look for certain tokens or pieces of data, process those, then hand it over to WordPress, or it may take certain pieces of information and remove it or direct it elsewhere into another application.
Whatever the case, this can just as easily be a few functions written as part of an mu-plugin in WordPress that it handles information or it can be a separate application that sits next to WordPress or in front of WordPress that processes the data.
In one of the projects I’m working on, there’s a little bit of pre-processing that happens before it writes data to the database but only in so far as checking the integrity of the data. If something seems off, it’s not pushed through the system, and an error is returned.
4. The Data Store
Again, in many traditional WordPress set ups, this could be something as simple as a MySQL database or a more complex data store, such as reading and writing data to a cloud-based database.
There may be additional functionality related to this too such as keeping logs both on the device as well as on the web server to make tracing errors and supporting users a bit easier.
In the example I’ve used throughout this post, I’m using a standard MySQL instance and a traditional WordPress database and the iOS-device is using flat files and JSON.
Seeing It All Together
I know I’ve been a bit vague in terms of the type of application I’m talking about throughout this article and there are reasons for doing so. Suffice it to say, when it’s ready for release, I’ll talk more about it.
But the gist of the functionality of the application still gives a good example as to how the aforementioned headless application structure works. Seeing it all together, this is how the flow of data from device to Headless WordPress and back looks:
- The device registers an account with the WordPress installation via the API.
- When the device authenticates with WordPress, it will periodically send the data stored in JSON via the REST API.
- The processor, built as a WordPress plugin, will handle the incoming information and either serialize it or return an error.
- Upon request, the history of serialized data can can be returned it to the iOS device and rendered as it suits the UI of the application.
- Upon request, all of the serialized data can be viewed per user in a web-based application that retrieves the information from the WordPress datastore. This information can either be seen in the WordPress administration area or in a custom report that communicates with WordPress.
Headless WordPress in 2023
Building headless solutions with WordPress in 2023 is still exciting. There’s a general pattern to which most solutions can be reduced and the complexity doesn’t lie so much with WordPress itself as it does with any tertiary components that may interact with it.
It’s still an exciting part of the application and it still allows for us to do some really cool things with WordPress. That said, the Block Editor and Full Site Editing have overshadowed much of what the core application is capable of doing. And it’s not that they don’t deserve the attention they get, but maybe we should continue talking about other aspects of what WordPress can also do.
And I contend this is important, especially if WordPress continues to aim at being the operating system for the web.
