The world of software development changes at a rapid pace. One of the most frequent complaints we hear about WordPress is that it isn’t “sexy” enough for modern developers – it is over a decade old after all. Regardless, there’s a reason it powers 25% of the web: it’s well known among developers, has an enormous community, a huge ecosystem of themes and plugins, and you can basically use it for anything that you like – blogs, corporate sites, social media portals, ecommerce powerhouses and more.

With the recent addition of the official REST API developers are being empowered to decouple the back-end of WordPress from the front end. The possibility to develop JavaScript-only applications that rely on WordPress to provide back-end business logic and data storage solely via its REST API interface is now a reality.

One of the best examples of what’s to come in the following years is Calypso, the rethought admin interface that is now behind WordPress.com – and some self-hosted sites, but the installation is not that easy, yet. Calypso is a React based application that communicates with the WordPress back end through JetPack’s API as WP’s core REST API is just not there yet in percentage of function coverage.

The Rest API is great but GraphQL is even better.

There’s a new kid on the block that will most likely put all REST APIs in the world out of work soon. It is called GraphQL (read the official announcement post with a lot more details here) and it’s a direct replacement for REST.

GraphQL represents a new ideology that makes it possible for the client or consumer of the data to declaratively specify the data it needs for each element. This means that, for example, you can attach a GraphQL specification to a React component and tell the server what kind of data you’ll need and in which exact format, nothing more, nothing less.

With REST APIs you have a set of predefined end points that, when queried, will always send you the same exact answer that you (as a front end developer) will have to manipulate on the client side until you get the elements and format that you’d like to use. With GQL it’s the exact opposite and makes the lives of front end developers a lot easier!

This leads to less data transfers, leaner code and most importantly – a faster web experience, especially on mobile devices where bandwidth is still an issue.

If you’re as excited about this new technology than we are, that’s awesome because we think it’s a truly revolutionary way to create applications!

GraphQL is awesome, however what good does it do for WordPress developers? If you’ve been paying attention WordPress development is shifting towards JavaScript development a lot lately and there’s a very interesting project started by Ramsay Lanier, a senior web developer at nclud in Washington D.C., called WordExpress. We got in touch with Ramsay and he agreed to do an interview with us on this exciting topic:

WordExpress

Can you tell us a bit about yourself?

I’m a senior interactive developer at a creative digital agency in Washington, D.C. called nclud. I work primarily with presentational level javascript, though I do consider myself a full stack javascript developer. In my spare time, when I’m not developing silly emoji-based applications, I’m attempting to be a good father to two very young daughters. I’m trying to get them interested in STEM, but they are still pretty young – it’s never too early though!

You work with WordPress every day, what is your area of focus?

At nclud we design and build highly interactive websites and applications. We work with a variety of content management systems, though we primarily use WordPress because our clients find the editorial flow of WordPress to be easy. As a senior developer, I work on all aspects of the build – from custom PHP themes to crazy canvas-based animations.

How did you come up with the idea for WordExpress and what is it?

WordExpress is my attempt at replacing PHP with Javascript in WordPress development. Its built using Node.js and Express on the back-end, and React on the front-end. In between, there is a GraphQL server that hooks into a WordPress database.

The main reason for this project is because I wanted to be able to develop WordPress sites using React components and CSS Modules. CSS Modules are awesome because they allow you to create locally scoped CSS specifically for each component. To get data from a WordPress database I initially tried using the WordPress API. I quickly found that it was pretty limited with what I wanted to do, and that I would end up having to write a bunch of custom REST endpoints. Also, GraphQL and Relay are still pretty new and I wanted an excuse to learn it.

GraphQL and Relay are really the big keys to this project.

What’s the main difference between working with the REST API and GraphQL/Relay?

With a REST API, you are creating a request from the server, sending it to the client and making the client parse through the data to get what it wants. Often times, you’ll have to make calls to multiple endpoints to get the entire dataset you need. While REST has revolutionized the way we do web development, it definitely has its downsides.

Facebook’s answer to REST is GraphQL. GraphQL is a very powerful database querying language that is able to describe complex, relational data. It allows the client to determine the exact dataset it needs and requires only one round trip from client to server and back. Its database agnostic too!

Relay provides data-fetching capabilities to React components and was designed to work specifically with GraphQL. With the GraphQL/Relay setup, a component determines its own data requirements by defining a GraphQL “fragment”. Before your application renders, Relay travels through of the Components that have fragments and build one (usually large) query which is then sent to the server. Its extremely fast and efficient. With Relay, you also get client-side data caching. For example, when you land on a blogroll page, all the data from each blog post will be fetched and stored in a client-side cache, so when you go into a blog post and then back to the blogroll page the server won’t have to fetch any data again – it’s already there!

Based on your experience do you think that GQL/Relay is superior to using the REST API (with WordPress)?

It’s absolutely better. It requires a different design approach, but its much more efficient.

How’s the initial feedback regarding WordExpress? What are people’s thoughts?

Its been great! I started this on a whim just to see how far I could get. I really didn’t think it would get much attention – but the project has gotten over 800 stars on Github. I do get a lot of questions, though – the biggest is probably how this project changes the administrative side of WordPress development. My answer is: it doesn’t. It still uses the tried and true WordPress admin panel.

I think there is still a good portion of people who don’t really understand how WordExpress works or what it’s trying to accomplish. I’m still working on writing a series of articles that explains the project in detail. I’ve written an introductory article that explains “why”, and two articles detailing how GraphQL and Sequelize work. There is more to come.

What are your current biggest problems with the implementation of this new methodology?

The biggest criticism is that WordExpress doesn’t work with the majority of WordPress plugins. It’s true – any plugin you use that affects things on the front-end won’t work. You can still use plugins that affect back-end stuff, like Advanced Custom Fields, or WP-Types (which I use). The benefit, though, is that because it’s built using Node, you can use any NPM package you want, so that’s the trade-off.

Also, server-side rendering doesn’t currently work which is a big issue. Right now, you don’t get any SEO because the HTML is rendered on the fly – I’m actively working to get server-side rendering to work with Relay and GraphQL and it’s pretty close. There has been some great work in the GraphQL/Relay community to support this.

Do you have any plans to use the new technology to improve wp-admin? (I’m referring to a Calypso-like project.)

Not currently – I haven’t played around much with Calypso. I’m generally pretty happy with the admin experience from WordPress. There are a lot of things still left to tackle to get the front-end development experience to where I want it, so I’m focusing on that.

If people want to contribute how can they reach you?

Twitter is the best way to reach me directly. If you want to submit pull requests – I’m all for it! I actively review PR’s and GitHub issues so I promise they won’t linger.

Thanks for taking the time to do the interview, Ramsay!

Here at Kinsta we think that GraphQL represents the dawn of a new age in web and application development and that we’ll see truly revolutionary solutions in the next few years that take advantage of these awesome technologies.

If you want to read more about GraphQL we included a couple of resources below, if you’d like to add more just post a comment below or send us a message!

Documentation

Courses / Lessons

Videos

Related Article:

HHVM vs PHP 7
Mark Gavalda Kinsta

Mark has many years of experience leading teams in the fields of marketing, web design and development. As a dev guy he used his WP expertise to collect the know-hows of creating a reliable and customer friendly hosting company to satisfy the increasing demand of clients. He is an urban cyclist and autodidact who never stops learning new skills.