WP Engine Launches Faust.js, a New Headless WordPress Framework

WP Engine has launched Faust.js, a new headless framework that is open source and designed to work in any Node hosting environment. The framework is built on Next.js, which can handle both static site generation and server side rendering. It uses GraphQL for data fetching and is the only framework that allows developers to query the WPGraphQL API without having to know GraphQL queries ahead of time.

Faust.js was in its earlier stages when WP Engine hired WPGraphQL creator and maintainer Jason Bahl. The company has been heavily investing in headless infrastructure development, hiring more engineers for projects aimed at reducing the friction of using WordPress as a headless CMS. This is the main thrust of the new framework – to allow developers to build scalable, better performing sites with modern frontend tools while preserving WordPress’ rich publishing experience. Faust.js includes content previews, support for custom post types, and built-in authentication to support paywalls, e-commerce, membership sites, and other functionality that has traditionally been difficult for headless sites.

How does Faust.js differ from existing headless solutions like the React-based Frontity framework? Developers building headless sites are curious after Automattic acquired Frontity and the framework’s maintainers exited to work full-time on Gutenberg. Using a community-supported headless framework can be a risky bet for enterprise clients when its creators and maintainers are no longer able to contribute.

“Frontity and Faust are similar, the main difference is that Frontity focuses on providing a framework on-top of React where Faust is primarily built with Next.js support in-mind,” Faust.js creator William Johnston said. “This small distinction is meaningful and means when you are using Faust you can take advantage of all the amazing benefits of Next. It also lets Faust focus specifically on how to make Headless WordPress a better experience, without having to come up with a comprehensive solution for front-end, node-base, static/server-side applications.

When asked how Faust stacks up to Frontity in a comment on Reddit, WP Engine developer relations engineer Kellen Mace highlighted a few other major differences between the frameworks. Frontity only works with the WP REST API and Faust uses WPGraphQL “for more efficient queries.”

“Technically, Faust is built in ‘layers,’ so even if you choose to build your frontend app using SvelteKit, Nuxt, etc. you can still leverage several of the tools Faust provides,” Mace said. “We’ll have more documentation coming out on using it with other JS frameworks in the near future. Using it with Next.js gives you the most ‘bang for your buck,’ however.”

Johnston confirmed that certain elements of Faust (the core/React pieces), are already working with the React-based GatsbyJS framework. Faust is less opinionated about the frontend and is more centered around making the WordPress publishing experience better.

A demo of Faust in action is available at developers.wpengine.com. The framework, which includes NPM packages and a WordPress plugin, can be found on GitHub, but its maintainers caution that there will be breaking changes in the future. Developers who are interested in learning more about Faust.js can check out the documentation or listen to the most recent episode of the DE{CODE} podcast where Johnston discusses headless WordPress and introduces the framework.

6

6 responses to “WP Engine Launches Faust.js, a New Headless WordPress Framework”

  1. I doing tests Frontity about 1,5 years ago. I liked it in the beginning because it was specially designed for use with WordPress. But the use of the Rest API was getting really frustrating, because you needed to call upon call, when you needed to get data about requested data. With GraphQL, it’s very easy to dive deeper into this and pack it all in one single call.

    With Faust.js things get even easier because you don’t even need to write out the queries as it’s been done with the framework. In practice, to me this is even easier than what PHP developers are accustomed to. The fetching is being done by the framework under the hood.

    • It’s great that batching for REST was added to core!

      It’s still not quite the same as GraphQL that allows you to batch, but also follow nested resources.

      Like:

      {
      posts {
      nodes {
      id
      title
      author {
      node {
      id
      firstName
      avatar {
      url
      }
      }
      }
      categories {
      nodes {
      id
      name
      }
      }
      }
      }
      }

      with REST, even with batching, you’d still need to wait for the initial response for the posts endpoint to come back, then the client would have to parse that response, figure out which IDs and endpoints are relevant, then make the follow-up batch request for authors, categories, etc, but then for the next set of nested resources, like user avatars, you’d have to make more follow-up requests and track how it all comes together in the client.

      Definitely a nice improvement for the core REST API to have batch requests, but it doesn’t quite solve things for client developers that GraphQL does.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.