Meteor + React with a headless Wordpress API

You know the story, the client wants a website; they only know about Squarespace and Wordpress, but they want a bunch of app-like-features. You also want to protect the site from being a target of intrusion like every other Wordpress site on the web. The choices have gotten a lot better, and the security and workflow has improved greatly, especially with services like Pantheon. But as a Javascript developer the last thing I want to do is rely on a bunch of plugins (wordpress plugins… written like 10 years ago and rely on like jquery, jquery-ui, boostrap ect just to make a form…), or write some SOAP integrations in PHP. So I choose to get the best of both words and use Wordpress only as my CMS and combo it with Advanced Custom Fields so the client can control absolutely everything on the page. From there we can easily construct react components that take in various flexible content fields and allow for really dynamic experiences on the frontend.

Wordpress Stack

This is pretty standard, I use Pantheon as my goto Wordpress provider, then I drop in ACF for adding custom fields to post types/pages. You can of course just use Wordpress as the blog and maybe don’t even need ACF. Then I drop in either WP Rest API or the JSON API for querying the data. In a previous post I talk about using the JSON API to hook up a load more button, in this post I’m going to use the WP Rest API. I’m not going to go any further into the Wordpress, assuming you only need a blog or to set up some custom post types you should be all set, the API plugins do most the work out of the box so we just need to hit the routes to pull in the data.

Meteor Backend

Meteor might seem like overkill but for the purpose of this article, and for the purpose of explaining the concept it’s the easiest to get up and running quickly, and if you have experience with other Javascript backends this approach should be easily adaptable. The nice thing about how we’re going to be using Meteor is that we’re actually going to be storing all the data from Wordpress in Meteor collections. The reason we do this is to easily pair the data with mini-mongo and handle some of the routing without any surprises from the Wordpress side, it also means our data loads really fast and never has to wait on the requests from Pantheon (no matter how fast it is).

Small note, I’m using Heroku to manage this particular Meteor build, with the Horse Buildpack for compiling.

Grabbing the page data

So let’s grab some data and put it into our collection (this is all at the server level):

You’ll notice we’re using upsert, this way we only update when data has changed. We’ve also defined a simple Pages collection for those of you not familiar with how Meteor handles collections. Now we need to tell our application to query that data for that I use Synced Cron a meteor package, but you could set up your own cron however you would like.

With the Sync Cron package you can easily define a task that runs at an interval you specify. I choose once an hour, this could be scaled back even more, or a route could be set up for the client to manually force the refresh, but 1 hour seems to do the trick just fine. So now we have our pages collection being pulled from our headless Wordpress instance and being dumped into our local mongo instance. We also need to set up our publication so we can grab the data in React:

React + Flowrouter SSR

I’m still a bit slow to adapt the React Router conventions, I’ve been a fan of Flowrouter since it came out and I know how to use it, so if you’re not into Flow you can sort of skip this bit. I’m going set up our index route, for those of you that have built custom Wordpress sites I’m sure you’re all familiar with creating something like a homepage and then in your settings assigning the the front page of the site to be that particular static page, we’ll be doing the same thing but in our React app. Since we’re using SSR all of the following is dropped within the both folder, those of you familiar with Meteor are used to server vs client in terms of file structure, for this situation we use both to handle rendering data on the server & client because if Facebook can’t query the page then what’s the point?

The above is pretty standard for flow router implementation, I have a Layout component that has our footer/header and then mounts the content and some additional data passed into it. I’ve also set up a bunch of DocHead stuff, this is because React Helmet doesn’t seem to play very nice with Flowroter SSR yet, so this is the only way we can pass Meta data if we’re using Flowrouter. We’ll go ahead and take a look at the container that’s pulling the data from our mongo instance here:

We’re using react-komposer to wait for the subscription before mounting. Once the data is loaded we pass it into our HomeComponent and display it:

Depending on how you have everything set up you may not need something like a Components module, but I generally build all my Wordpress stuff with ACF flexible content layouts, so I can easily build dynamic/different layouts for clients, You might only need to display props.page.content for example, just make sure you render it dangerously.

If your curious about the Layout Component:

That’s it in a nut shell, for anyone looking to build big applications but still leverage the power of something like Wordpress from a content production standpoint I hope you’ll find this to be a possible solution. I’ve seen this implemented with no issues with React Router as well, and I’ve also seen Prismic used as an alternative to Wordpress.

~~Happy Coding~~