Integrating WordPress in a webservice architecture

With the introduction of the WP REST API, I think WordPress is taking a step in the right direction to becoming more adaptable to a wider variety of needs. With a few easy techniques, we can easily build much more complex applications, which use WordPress for what it’s best for.

The problem with the default implementation of the REST API is that it relies on sessions for storing authenticated user’s data. This means, that if we want for WordPress to play well with a host of other services, all the requests must go through WordPress to handle the security of those requests.

Example Application

Let’s say we are building an application consisting of 2 web services. One is WordPress with EDD installed, to handle users and payments. The other web service is a component that allows the users with the right subscription to post messages in a chat, of course this could not be easily written in PHP, so we should choose NodeJS, Golang, or something like this. And we also have a frontend application written in Vue.

So our architecture would look like this:

WordPress webservices

Traditionally, to connect these 3 services, we would make all the calls from the frontend through the WordPress REST API, so that we can authenticate the user the request comes from. So basically, WordPress is transformed into a proxy, something it was not designed to do. This could quickly become a bottleneck in our application. This would look like this:

WordPress webservices

You can see how quickly WordPress can become a bottleneck in our architecture. This is not very scalable or easy to change. Every new API endpoint that we will create in the Node application, will need to be added to the WordPress side, so that it knows how to forward it.

Introducing JWT

One main requirement of an API to be considered RESTful, it is to be stateless, that means no extra info about the request should be stored on the server. This is a bit hard to do using session based authentication, because the sessions are stored on the server.

What JWT allows us to do is, hold the current user’s data on the client. This will be encoded with a secret key so that the user isn’t able to tamper with it. By doing this, we will be able to call other services using that token, and every server that shares the key will be able to know from what user the request comes from.

How does this work?

Well, the new process would work like this:

  1. The user enters his username/password in the Vue frontend app
  2. The Vue app makes a call with the username and the password to the WordPress service that holds the user information
  3. If the user data is found, WordPress can now respond with an encoded token containing that user’s id, name and whatever other information is needed
  4. The Vue app stores this token in local storage, or in a cookie, and uses it to make calls to the other services.

Now you can see we have eliminated WordPress as a bottleneck, and all the calls can go directly to their relevant services:

WordPress webservices

As you can see, this app becomes much more scalable, and WordPress isn’t a bottleneck anymore. This becomes even more obvious if we would have multiple services in a more complex architecture.

This opens up a whole new realm of possibilities, scaling horizontally is much easier, because each request can go directly to the relevant service.

I think that the WordPress JWT plugin should be given much more attention than it gets, and not as a side note on the REST API authentication page.

Let me know in the comments if you have any questions, or would like more details about this in future blogposts.

 

Ovidiu Maghetiu

Passionate Full-Stack Developer with more than 10 years experience in building complex web apps.