In collaboration with:

Building Calypso like applications with the WordPress REST API

Nikolay Bachiyski offers a walkthrough of building a single page application similar to Calypso using the WordPress REST API and React.

You can view all videos as we release them on the A Day of REST video archive.

Nikolay Bachiyski is a developer at Automattic and he was a member of the team that built Calypso, the new WordPress.com interface that runs on the WordPress.com REST API. In his talk at A Day of REST, his aim was to share what they learned building Calypso and how their experience can help others build similar applications.

Calypso is written almost entirely in JavaScript. You can read more about the launch, or listen in on an interview I did with Automattic CEO Matt Mullenweg for more information. You can use the WordPress.com interface to read blogs, or write on them, whether they are hosted on WordPress.com or powered by Jetpack.

Goals and tools

The goals for Calypso were the following:

  • A better user experience, that’s faster and more intuitive
  • Faster product iteration, since the traditional admin is difficult to adjust
  • A better developer experience

Nikolay outlines the primary technologies used by Calypso: ES6, React, Webpack, Redux, and React-Router. It’s also worth noting that most of the code for Calypso is open source and on Github.

For routing, Calypso uses page.js (though they wish they could’ve used React Router, but it was just coming out). You can see a full list of dependencies on the package.json file.

Much of what is actually sent to the page in Calypso is sent via React components, primarily made up of HTML and JavaScript. The data itself is delivered from the WordPress.com REST API, and once version 2 of the WordPress.com API is released, it will actually utilize the WordPress REST API.

Data collection and display

One of the challenges with Calypso was managing when to get data within components. Sometimes, it makes more sense to let an individual component retrieve the data, rather than trying to grab everything that may be needed with the primary component. They call these “smart” or “connected containers,” for situations where it’s better to let child components get the necessary data so that the initial data transfer tax is less burdensome.

Utilizing smart containers, you could run into situations where you grab the data within one component, and then another component uses the same data — so you need to ensure that you keep the same values. They use “stores” in a global state for user and post data, which each smart container listens to; and Nikolay says this is one of the biggest differences, “from a classic web application, because we can do these things synchronously,” because they can render the component before the data is even there, so even if it’s not fast, it can deliver an experience that feels faster, because the user, “feels like something is happening.”

I used my ninja screenshot speed skills so I can show you what Nikolay means with this:

wpcom-container-preload

Flux and reusable components

Automattic is using Flux along with React in order to maintain reusable components. Additionally, they have their own reusable components they created in Calypso.

What’s in it for folks not building Calypso?

Nikolay acknowledges that there are many things that are particular to Calypso itself, but not necessarily important for anyone building other REST API driven applications. So he brings up a variety of points to highlight questions and considerations to take into account when building  similar applications.

Do you need a single page application?

  • Maybe if you have a lot of user interaction?
  • Do you need quick transitions between interactions?
  • Do you have multiple front-ends for a single application (mobile, web, etc)?
  • Do you have a team with significant JavaScript chops?

If you answered “yes” to those questions, then a SPA might be for you. If not, you might want to think more deeply about your needs, and maybe traditional web apps could suffice.

Other tools for building SPAs

React isn’t the only option, and Nikolay has a few technologies you may want to check out as well:

  • Ember, which feels similar to Rails
  • Angular, backed by Google, and version 2 has a lot of promise

The reason Automattic chose React was primarily for flexibility, and how fast React is evolving, whereas the other projects aren’t moving quite as quickly. However, he warns that your team will need a deeper understanding of how everything works. He says, “Shooting yourself in the foot is easy, if you don’t know what you’re doing.”

React tools to check out:

Finally, Nikolay wants to make sure you don’t get too caught up in FOMO (fear of missing out), as the JavaScript world moves so fast that it’s easy to get caught up in the new stuff that’s coming out every single day.

You can follow Nikolay on Github or Twitter, and view his slides as well.


The videos at A Day of REST were shot and edited by Rhys Alexander. The conference was organized by Human Made, and you can stay up to date with A Day of REST — which is going to Boston — and learn about other potential future events. There were eight great talks at A Day of REST, and you can read my review of the event as a whole, and look out for the next video to be posted here soon.