WordPress with Node, React, and GraphQL (Part 1 — Introduction)
What follows is my attempt to replace PHP with Javascript in WordPress development.
UPDATE: I’ve since created a newer version of this project using Vue instead of React. You should read about it!
Index:
Part 2 — The Setup
Part 3—The Schema
In the following weeks, through a series of articles, I’ll explain how I’m using Node.js and Express on the backend with a GraphQL server hooked up to a MYSQL WordPress database that uses Apollo to fetch data and pipe it into React components. Don’t worry, I’ll still be using the tried and true WordPress admin interface.
If that sounds like a mouthful, that’s because it is. It’s been challenging, especially because this is my first foray into GraphQL and Apollo. Things will change. Change is good.
This post will explain why.
Why Did You Do This You Silly Person?
WordPress is a giant. 25% of all websites are built on WordPress. It’s a great CMS, with a great community, and great support. Managing content is easy and that’s the main goal of any CMS.
At nclud I develop WordPress sites daily. Administering WordPress websites is a treat. Developing them is not. I say this as a Javascript developer who has experienced what isomorphic Javascript applications look and feel like. Javascript got me twitterpated. WordPress development does not.
What can I say? I don’t like PHP. I don’t like templates. I don’t like “the loop”. I’ve become spoiled by Node, Express, Webpack, React, Babel, and now Graph QL and Apollo.
The Benefits Of Javascript
I’m coming at this purely from the front-end development side. Node and Express are awesome, but the main driving force behind this setup, for me, is the ability to use ES2015 with React and CSS-Modules.
The biggest challenge of developing and maintaining any decently sized website or application is the ability to gracefully handle changes (adding new features or modifying existing ones) without breaking stuff. This usually involves making sure that applying or modifying styles doesn’t have any unintended consequences. This is challenging considering CSS is globally scoped. There are entire CSS methodologies that were created to ease this pain (SMACSS, BEM, etc.) but the either involve esoteric naming conventions, or require you to remember a zillion different class names.
With React, we can use CSS Modules to create locally scoped CSS. Every component has its own styling, which the ability to compose CSS classes for other styles, or a set of global styles. It’s very powerful. It’s also not possible with WordPress.
You can also do inline styles, use JSXStyles or myriad other solutions — I’m a CSS Modules fan boy so that’s what I’ll be using.
This method also means that React components are easily switched out between projects. They are reusable, pluggable. Because styles are locally scoped to a component, you can add and remove them at will without having to worry about breaking something else.
Another benefit is the ability to handle application or website state is a much more graceful way. Using Apollo (which I’ll get into in another post) we can manage not just application data, but UI state. Too many times in WordPress I see one large javascript file that handles events and interactions for an entire website. Too many times do I see in that long file tests to see if an element has a class which should trigger an animation. This leads to painful debugging because application state is not consistent.
Lastly, we can also now perform unit tests. Testing is important! Huzzah testing!
Isn’t WordPress Already doing Node Stuff?
If you have been following WordPress news, you’ve probably heard that Automattic, the company behind Wordpress, has developed an admin interface built on Node. Its pretty sweet, and it’s been open sourced. Its powered by the WordPress REST API, so you can get all your WordPress-y stuff in JSON and do magic with it.
That’s pretty neat.
When I originally set out to try to replace PHP with Javascript, my first thought was to use this API. Its got some nice built in endpoints, and you have the ability to create your own. The V2 documentation is a little lacking, but I just chalk that up to it being so new.
I wasn’t terribly happy with the result, though I’ll admit I only played around with it for a day or so. Also, since I’m already using React, I might as well embrace the entire ecosystem.
Enter GraphQL
Wouldn’t it be great if our application or website’s UI could drive what data it needs? With REST, the server sends all data the UI might need, then lets the client sort through the rest. You might need to make calls to multiple REST endpoints to get all that possible data.
With GraphQL, the client determines the relationships of data it requires and makes one query to fetch it all. There is only one trip. And you get exactly what you need.
Anyway, you can read more about GraphQL vs. Rest here.
Next Steps
I’m my next post, I’ll walk through the basic Node.js/Express setup and how to setup the basic GraphQL server. I’ll also walk through how I’m using Webpack to handle CSS Modules with SASS, how hot module replacement works. I’ll also being using Sequelize to create a connection to a WordPress MYSQL database, which means we won't have to write ONE SINGLE LINE OF SQL QUERIES! Wizardry!
In the meantime, I’ve got a Github repo that contains where I am currently at in this process. It’s got some basic Post and Postmeta queries and some other neat stuff. It's obviously under active development, and I’m sure there are some embarrassing mistakes in there, so feel free to poke fun.
Ramsay Lanier is a Sr. Developer at nclud, a provocative digital agency in Washington, D.C. You can find him on twitter, github, or at &pizza.
