Category: Announcements

On February 1, I announced that I was no longer employed at Gatsby, and stated a blog post would be coming soon.

This is that blog post.

TL;DR

I’m joining WP Engine as a Principal Software Engineer where I will continue maintaining WPGraphQL and will contribute to other projects and initiatives centered around the goal of making WordPress the best headless CMS.

Below I will expand a bit more on “Why WP Engine?”, but first, I’d like to take a moment to reflect on my time at Gatsby and acknowledge how important Gatsby is to the future of headless WordPress.

WPGraphQL and Gatsby

I am incredibly thankful for the opportunity I had to work at Gatsby to push forward WPGraphQL. Gatsby’s investment in WPGraphQL led to a lot of growth and maturation of the project

Project Growth and Maturation

I joined Gatsby in June 2019, and since then, WPGraphQL went from:

• v0.3.5 to v1.1.3 (53 releases in that time)
• ~15,000 installs reported on Packagist.org to +85,000 reported installs
• Not available on WordPress.org to available and +8,000 active installs reported

Community Growth

In addition to the growth and maturation of the core WPGraphQL plugin, the community around it has also grown.

While I believe WPGraphQL would have seen growth in the community regardless, I believe we can attribute at least some of this growth to Gatsby’s investment in WPGraphQL. Gatsby’s investment in WPGraphQL signaled that it wasn’t just a hobby project, but was solving real problems for real users, and users should have confidence using it in their projects.

When I joined Gatsby to work on WPGraphQL and collaborate with Tyler Barnes on WPGatsby and Gatsby’s new WordPress Source Plugin, the JavaScript ecosystem paid much more attention to using WordPress as a headless CMS, and the WordPress community got more comfortable using WordPress in ways they hadn’t before.

Many agencies, developers and site owners now consider WPGraphQL an essential part of their stack.

WordPress plugin developers have now created more than 30 WPGraphQL extensions, and there are now more than 1,500 people in the WPGraphQL Slack!

Agencies such as Zeek Interactive, WebDev Studios, 10up and Postlight use and recommend WPGraphQL for headless WordPress projects.

Websites such as gatsbyjs.com, qz.com, denverpost.com, diem.com, apollographql.com, bluehost.com, rudis.com and many more are using WPGraphQL in production.

So, why leave Gatsby?

Gatsby has been incredibly generous in funding open source developers to work on projects related to, but not part of Gatsby. For example, John Otander was working on MDX, Rikki Schulte was working on GraphiQL, and I was working on WPGraphQL.

I was the last remaining of these engineers working primarily on other projects that tangentially, but not directly benefit Gatsby.

WordPress is only one part of Gatsby’s story. Gatsby can work well with just about any data source. Some popular non-WordPress choices are Contentful, Sanity, DatoCMS, Shopify, among many others.

The team I was part of was asking me to start transitioning to work more on other Gatsby integrations, such as Contentful and Shopify, and work less on WordPress and WPGraphQL. This doesn’t mean Gatsby was abandoning WordPress or WPGraphQL, just that I would need to spend less time on it and prioritize other things. There’s nothing wrong with this. There’s a lot of sound decision making to this when it comes to making Gatsby a sustainable business.

I feel right now is a unique time in history where more investment in WordPress as a headless CMS can change the future of WordPress. I believe WordPress is now more respected as a viable option for a headless CMS and that with the momentum of WPGraphQL, technologies like Gatsby, NextJS, and others, I need to spend more time focusing on WPGraphQL and headless WordPress, and not less time.

Fortunately for me, WP Engine is investing in the future of headless WordPress, and they see WPGraphQL as an important part of that future.

As ironic as it may sound, I believe that my departure from Gatsby will actually strengthen the WordPress + Gatsby integration.

Instead of partially focusing on the Gatsby side of the integration and partially focusing on the WordPress API side of the integration, this move will allow Gatsby to hire a backfill for my position to work specifically on the Gatsby side of integrations, and not have to worry about the WordPress server API side of things. This allows the team to narrow their focus and deliver higher quality code on the Gatsby side of the Gatsby + WP integration.

I intend to continue working with Tyler Barnes and the Gatsby Integrations and Collaborations team to ensure that users of Gatsby + WPGraphQL feel supported and productive. Gatsby + WPGraphQL will continue to play a big role in the future of Headless WordPress, and I’m here for it.

Why WP Engine?

Serendipity, at least to some degree.

Within a few weeks of having conversations about needing to start focusing less on WPGraphQL at Gatsby, I discovered that WP Engine was building a headless WordPress framework and was hiring engineers to focus on headless WordPress. The job description felt like it was describing me, almost perfectly. Serendipity.

A few years ago, prior to my time at Gatsby I was interested in a position at WP Engine. But at the time there was a hard requirement for employees to be in Austin, TX. I have so many friends and family members in Denver that I have no plans to move if I don’t absolutely have to. WP Engine no longer requires employees to be in Austin, so I could now work for WP Engine without needing to move. Serendipity.

Along with the serendipitous aligning of stars, WP Engine is a generally attractive employer.

WP Engine is a leader in the WordPress space. I’ve trusted WP Engine to host many sites I’ve worked on over the last decade, including WPGraphQL.com and jasonbahl.com.

While WP Engine’s primary business is managed WordPress hosting, it also invests in a lot of products and projects that make it easier for businesses to run their sites on WordPress.

Projects such as LocalWP (that I gave a shout out to on Syntax.fm in Jul 2019) and Genesis Blocks are thriving under WP Engine, and I believe that WPGraphQL can continue to mature and thrive with WP Engine’s support.

WP Engine’s investment in headless WordPress isn’t limited to me joining to continue working on WPGraphQL and other headless WordPress projects. There will be more hires and projects aimed at reducing the friction of using WordPress as a headless CMS, and allowing businesses to get started and move faster within that context.

I believe that WP Engine’s investment in this space will allow WPGraphQL to grow and mature faster than ever before, as I will be part of a larger team working to make WordPress the best it can be.

So, does WP Engine own WPGraphQL?

Before my time at Gatsby, during my time at Gatsby and now as I transition to working at WP Engine, WPGraphQL has and will continue to be operated and maintained as a free, open-source community plugin benefitting anyone using WordPress.

WP Engine pays my salary, and in exchange I will be maintaining WPGraphQL and helping grow the headless WordPress ecosystem, reducing friction in many different ways.

What’s next for WPGraphQL?

I can’t officially commit to any of these things quite yet, but some things I have on my radar to tackle in the near future include, but are not limited to:

• Significant updates to WPGraphQL for Advanced Custom Fields
• Updates to the GraphiQL IDE that ships with WPGraphQL (testing as public and authenticated user, for example)
• Introduce new Custom Scalars (datetime, HTML, among others)
• Add Support for Image Uploads
• Update Schema surrounding Media
  • Introduce a MediaItem interface and different GraphQL Types for Image, Video, etc
• New tooling to help developers move faster
  • Query / error logging
  • Breaking change notifications
  • Persisted Queries
  • Query Complexity configuration and analysis
• WPGraphQL Subscriptions (real time updates when data changes)
• Component library(s) using WPGraphQL Fragments
• More tutorials, videos, blog posts about using WPGraphQL in various contexts

I’m excited to get started at WP Engine and work on the next chapter of WPGraphQL and headless WordPress! I hope to have a more formal roadmap to discuss with the community in the near future, once I get settled as a WP Engine employee.

I’m so thankful to the community that has embraced WPGraphQL. I feel so much love and appreciation from thousands of developers that are using, contributing to, and providing feedback for WPGraphQL.

I’ve made many genuine friends from the WPGraphQL community and I am so thankful that this next chapter of my career allows me to continue working in this community.

I’m so excited to announce WPGraphQL 1.0!

If you’ve been using WPGraphQL for your side projects, but are waiting for the “stable” version, then this is it! You can use WPGraphQL in production with the confidence that it is secure, well documented, and supported full time and long term.

If you’re new to the WPGraphQL community, you may ask yourself, “But WordPress already has the REST API. What’s different about using WPGraphQL?”

Well, when you use WPGraphQL to turn your WordPress site into a GraphQL server, multiple resources can be fetched at the same time. And by design you get back the exact data you asked for, nothing more, nothing less. In addition to being easier to work with compared to the REST API, data loading with GraphQL is faster and more efficient. (Read more: “WPGraphQL vs. WP REST API“)

If you are upgrading to 1.0 or another version, see the release notes for information on breaking changes and preparing your site. If you are new, start at the homepage and follow our step-by-step docs.

In this post I want to talk about the journey to 1.0, why it took so long to get to 1.0, and a look at what’s next for WPGraphQL. But before diving into that, I want to also announce some other fun stuff that has also come to life along with this release.

• WPGraphQL is now available on the WordPress.org repository
• New WPGraphQL.com website
• WPGraphQL Swag available on the Gatsby Swag Store

WPGraphQL on WordPress.org

The WordPress.org plugin repository has long been the default distribution mechanism for WordPress plugins. Prior to today, developers had to install WPGraphQL using Composer and installing from packagist, or by downloading from Github.

Now, users can install WPGraphQL directly from WordPress.org’s plugin directory.

We believe that distributing WPGraphQL on the WordPress.org plugin repository should make it easier for users to find and install and keep updated.

New WPGraphQL.com website

WPGraphQL.com has been re-built from the ground up.

Before today, WPGraphQL had 2 primary domains:

• WPGraphQL.com, a “traditional” WordPress site using WordPress as the CMS and the theme layer
• docs.wpgraphql.com, a Gatsby site using Markdown files in a Github repository for the content.

Now, instead of splitting some content in Markdown files on Github and some content in WordPress, WPGraphQL.com now uses WordPress as the CMS for all content, and and has a Gatsby front-end powered by the new Gatsby Source WordPress plugin, WPGatsby and of course WPGraphQL.

We’ll be releasing tutorials and videos in the coming weeks and months walking through how various parts of the site were created to provide inspiration for you to build great things with this stack as well, but for now you can draw inspiration from the repository this site is built from: https://github.com/wp-graphql/wpgraphql.com

WPGraphQL Swag

Now, possibly the most exciting thing about this whole announcement, is the fact that you can now get WPGraphQL Swag from the Gatsby swag store.

The Journey to 1.0

WPGraphQL was started in November 2016 (with no commit message ???? ) and has come a long way in that time.

By the end of 2017 the codebase was pretty robust and provided a Schema to interact with many parts of WordPress. Posts, Pages, Custom Post Types, Tags, Categories, Custom Taxonomies, Comments and Nav Menus.

Qz.com was the first site to go to production with WPGraphQL, even before I was using it in production! A few years later and they are still running on WPGraphQL! You can learn more about the early days of their stack from this presentation from December 2017.

In early 2018, my team took WPGraphQL into production on a network of 54 large WordPress sites. WPGraphQL was used as a syndication engine for our network of newspapers. Unlike most GraphQL users, we didn’t initially have a JavaScript or native mobile UI that was using GraphQL, we had PHP WordPress servers syndicating content and GraphQL solved a lot of pain points we had been facing when using REST.

By the end of 2018, more than 100 sites were using WPGraphQL in some way.

Now, WPGraphQL seems to be running all over the place!

This is a non-comprehensive list of sites using WPGraphQL in production in some way:

• DenverPost.com
• TwinCities.com
• MercuryNews.com
• SiliconValley.com
• QZ.com
• MeowWolf.com
• ThePlayersTribune.com
• ApolloGraphQL.com
• blog.creditkarma.com

According to Packagist.org as of June 30, 2020 there were nearly 50,000 installs of WPGraphQL in the wild, and as of November 2020 Packagist reports 71,573 installs.

In 2019 Credit Karma paid for a security audit on the plugin and all reported issues were resolved.

It’s safe to say, WPGraphQL is production ready!

So, why the wait for 1.0?

So, if WPGraphQL has been production ready for such a long time, why is is still not 1.0?

Breaking Changes & WordPress

The WordPress ecosystem has a strong commitment to backward compatibility. This means that once functionality is introduced to a WordPress plugin, it often sticks around forever.

With that in mind, before tagging WPGraphQL 1.0, I wanted so badly to be at a place with the codebase & Schema that I could no longer predict anymore breaking changes.

I wanted the GraphQL Schema to be “perfect” before tagging it 1.0, because I knew that whatever would be in the WPGraphQL Schema at 1.0 would need to remain in the Schema forever. The WordPress community is used to things working the same way “forever” and I wanted to play along.

Breaking Changes & WPGraphQL

The reality is that for software to get better, sometimes it needs to make breaking changes.

WPGraphQL will never be perfect, and it will need to occasionally break to make things better.

For example, when the GraphQL Specification updates to include Input Unions or Interfaces that can implement other Interfaces, WPGraphQL will need to break to keep up with the GraphQL Specification.

There would be no way to keep GraphQL as we know it today and take advantage of tomorrow’s GraphQL Spec without breaking.

WPGraphQL turning 1.0 isn’t a statement that there will never be breaking changes, instead it’s a statement of stability and long term support.

So, how will breaking changes be handled in a post-1.0 world?

Semantic Versioning

WPGraphQL has been following Semver practices for a few years. We will continue to follow Semver and let version numbers communicate meaning. The summary of Semver versioning is as follows:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.

You can read more about the details of Semver at semver.org

Seamless Upgrade Paths

When WPGraphQL needs to make breaking changes to the Schema, there are sometimes ways to make the changes and allow for seamless upgrade paths.

What that means, is that WPGraphQL can introduce a new feature while keeping the old feature. For example, let’s say the following (hypothetical) query were in the Schema and the author field returned the name of the Author:

{
  book {
    author
  }
}

Let’s say we realized that the Author should actually be a one-to-one connection to an object with edge space for relational context. We would want to change the schema to allow for the following query instead.

{
  book {
     author {
         node {
             name
          }
     }
  }
}

If WPGraphQL made this change, any consumer application would break.

So, what we can do is introduce the new feature like so:

{
   book {
     author
     authoredBy {
        node {
            name
        }
     }
   }
}

We could introduce the new feature as a new field name authoredBy which returns the data in the shape we want.

The end goal, however, is to have the author field return the author.node.name shape.

So, with both fields (author and authoredBy) co-existing on the server, consumer applications could make use of GraphQL Aliases and update their code from:

{
  book {
     author
  }
}

to:

{
   book {
      author: authoredBy { # Consumer uses an alias to prepare for the upcoming change to the author field
          node {
             name
          }
      }
   }
}

Once consumers have updated their code, the server could then update once more to flip the old field name to the new shape. So, the next release would have the following possible:

{
   book {
      author {
         node {
             name
          }
      }
      authoredBy {
        node {
            name
        }
     }
   }
}

So now, the old field author no longer returns the name directly, it now returns the new nested node/name shape. The client is using an alias to query the authoredBy field, so now the consumer should update their code from:

{
   book {
      author: authoredBy { # Consumer uses an alias to prepare for the upcoming change to the author field
          node {
             name
          }
      }
   }
}

to:

{
   book {
      author
          node {
             name
          }
      }
   }
}

Now, the consumer application is using the new shape of data and the old author field, and one more release would be able to remove the temporary authoredBy field that was used for seamless upgrades.

The GraphiQL IDE is an incredibly helpful tool when using GraphQL. WPGraphiQL has been the go-to GraphiQL IDE for use with WPGraphQL, and today we’ve released v1.0.0 of the WPGraphiQL IDE, now with the AMAZING GraphQL Explorer feature, courtesy of the fine folks at OneGraph.com.

📢 v1.0.0 of the WPGraphQL IDE is here!

Features the AMAZING GraphQL Explorer from @onegraphio!

Enjoy!https://t.co/ZRkZU8Lmc5 pic.twitter.com/ucJlZEmrU0

— GraphQL for WordPress (@wpgraphql) August 13, 2019