Meet the Developers
First, let’s meet the developers we interviewed:
Libraries and Frameworks
I asked our developers, why do you use the framework or library that you use? As it turns out, three of our four developers choose to use React and the Redux framework, while one is strongly in favor of Angular. For those who may be unfamiliar, Facebook created React while Google created Angular.
For Jason Stallings and Jay Hill, React is the library their team and projects tend to use. Jason Stallings says of React, “It seems to be the framework that has “won” the framework war. Last year I attended the Chrome Summit and Google themselves spent the whole time talking about React. I like the amount of power behind it. I like the developer workflow as well.” What does he like about it?
“It’s declarative, functional, and forces good standards and principles.”
Nate Gay found his way to React as a solution to the jumble his original jQuery project had left him with. He uses Redux to manage state, and Axios as his library to make REST API calls.
Ben Moore, by contrast, uses Angular. His reasoning is simple:
“I love opinions and hate options.”
He says, “It just makes my life easier when I don’t have to think about the best way to do it when one of the best companies in the world already told me how they’re doing it.” Not only this, but Angular coupled with Angular CLI offers him the power he needs to work with large amounts of data in the Business Intelligence tools he creates. He does admit though, “for a website, you probably shouldn’t use Angular–it’s just overkill.”
Since our room was split for Angular and React, I asked our developers–was there any project in which you’d prefer to use another framework like Vue instead? All four agreed that for themselves in most cases, the answer was no. Ben Moore, as a proponent of Angular, does say, “I would look into it for smaller-scale components. I keep looking at a back-end dashboard or a plugins page, where you’re plugging into an existing project or site. Angular isn’t very good at piecing or piping into other things.”
As a user of React, Jason Stallings simply says no. “They solve similar problems. Vue might be a bit quicker to get the project up and running because it requires less “up front” transpilation and minification, but any modern framework should have that anyways.” All of our developers agreed that Vue is certainly the right choice for many users, even if it wasn’t their own framework of choice.
And sheer power was the driving force for Ben Moore. Building tools that query hundreds of endpoints for data in a quick and efficient way was key. “Everything that I’ve built is highly dynamic and I needed the least impact on the server as possible… I think I pull in hundreds of thousands of rows a day. I needed something more dynamic that can distribute those resources to the browser, and generate things on the fly instead of refreshing the page each time.”
Integrating with WordPress
One of the biggest problems in developing a Headless site is simply figuring out how to do it. Everyone seems to have a different answer. So I asked our developers: How have your apps have integrated with WordPress? Ben Moore uses a combination he likes to call “Brainless” WordPress. In that, he means “I use WordPress for back-end functionality on initial page requests. So it handles authentication and user management, and enqueueing assets. But the only HTML I want it to spit out is scripts, styles, and Angular instantiation. From there, Angular takes over.” On the front-end,
“As you click around whatever I build out, it’s straight API calls. It looks like you’re going from page to page, but it’s really a single-page web app.”
Jay Hill is creating a Progressive Web App. “I’m using the REST API to query data. It’s pulling the data and serves through my menu component through a plugin I’m using. My front page is just a list of blog posts, and in the menus it passes a slug as a query argument to be able to navigate each page.”
GatsbyJS has been the tool of choice for Jason Stallings. GatsbyJS is a static site generation tool that integrates with WordPress. That means, “You use React to structure your site the way you want, and then Gatsby is in charge of “sucking in” the data and rendering it as static HTML. GatsbyJS has a WordPress source plugin where it uses the REST API to pull your posts, pages, custom post types, and makes it available to you as a GraphQL server. You can then preview that data from your front-end. Google and Facebook work together so that it beats their Lighthouse test–any website built with Gatsby gets an instant 100.”
Challenges and Surprises
“Shortcodes don’t always work correctly when you’re pulling them through the REST API.”
By that he means, “a lot of shortcodes include HTML and JS and CSS on the page, and the shortcode itself spits out a div that has classes and IDs that the JS can use to recognize it and fill in the content. If you’re pulling the data from the REST API to render on another front-end, that JS and CSS doesn’t exist on the page. That was a big hurdle to get around.” He ended up using an HTML parser to look for those divs, strip them out, and replace them with a matching React component.
What does your development workflow look like?
There are a lot of conflicting opinions in the community over what the “right” development workflow is. I asked our developers what their workflow looks like, and got surprisingly different answers from each. For Jay Hill, it’s mostly trial and error at this stage. He reads documentation, tries a new task, and uses his diagnostics tools and resources to troubleshoot. Laughing, he says “If I still can’t get it, I ask Stallings for help.”
For Jason Stallings, working on a team means he uses Continuous Integration tools. “I develop locally, push to Github, from there TravisCI picks it up and does tests to make sure it loads in the browser, ensures I can click around, can I load a post, and then it does unit snapshot tests to make sure the components are rendering correctly too. Once all those tests pass, TravisCI pushes it to my live site on static hosting.“ His process is all automated. But that development pipeline does take longer than it would to just publish a new post on WordPress.
He says with this kind of workflow you should also consider,
“when you’re publishing content in the backend it has to go through this big pipeline, and that pipeline takes about 5 minutes from hitting publish to when it actually shows up on the front end.”
Five minutes may not sound that long, but for a publisher that can be quite cumbersome. Imagine noticing a typo in one of your posts. From when you click “update” on that post, it still takes another five minutes until it’s fixed on your site.
Nate Gay uses the Create React App for his development process, which means changes show up right away in his browser as he works. In his local environment he has an mu-plugin that disables authentication so it doesn’t interfere with his workflow. Of the deploy process he says, “My build tools for my plugin aren’t very pretty. It’s just a bash script that does the React build and takes the minified JS, zips it up, and then I can deploy it to my site.”
How did WP Engine help?
I was also curious how WP Engine came into the picture for our developers. Did the WP Engine platform prove to be beneficial in the development or hosting process? Jason Stallings says it does, particularly when it comes to caching requests to API endpoints.
“As long as you’re making GET requests to those endpoints then they’re cached, and they’re automatically purged from cache when you make updates to posts.”
Nate Gay also points out the benefit of WP Engine’s CDN for static file caching and geographical distribution. And great servers as well, says Jay Hill.