Faust.js Framework Guide

Faust is a JavaScript framework designed to make the development of headless WordPress sites as easy as possible for WordPress and JavaScript developers.

The mission of Faust is to reduce the complexity of building headless WordPress frontends for the web, allowing the developer to build production sites with the ease of a monolithic WordPress site.

Check out their documentation for guides to all these key features.

To get started, you can run the following command to create a new Faust.js project and the follow the steps in their getting started guide: npx create-next-app \ -e https://github.com/wpengine/faustjs/tree/main \ --example-path examples/next/faustwp-getting-started \ --use-npm

After you have created your application, cd into your project directory:

cd <your project directory>

To deploy your project to Atlas, it will need to be available on a remote GitHub, Bitbucket or GitLab repository. The Faust.js installation process lets us initialize a local repository for the project.

Create a new remote repository, and then run the following commands to initialize and configure your local and remote repositories:

# Add remote repository
$ git remote add origin https://<your-git-provider>/<username>/<repo>


# Stage all changed files
$ git add -A


# Commit the files to the current branch
$ git commit -m "initial commit"


# Push changes to remote repository
$ git push -u origin main

Once your project is in your remote repository, you can follow the directions in our getting started guide to deploy your project to Atlas.

Atlas detects that it is a Faust.js app and runs the build scripts and configs necessary for the build details.

One thing to note is the next/cache folder within your Faust.js project. Atlas caches common framework assests between builds to optimise build times.

The build step will not override the folder.

The Next.js Image component, next/image, is an extension of the HTML <img> element, evolved for the modern web. It includes a variety of built-in performance optimizations to help you achieve good Core Web Vitals.

One thing to keep in mind is when switching over your domains on Atlas, you must declare them in the next.js.config file, otherwise the images will not render.

While our Node infrastructure will support path-based revalidation on-demand, this revalidation will currently not extend to edge cached versions of that path, nor will they apply to all instances of your front-end application (if scaled beyond a single instance). This is under active investigation by our engineering team.

By default, Next Image serves up WebP versions of images to browsers that support it, and the AVIF format can also be delivered through configuration. While Atlas supports the delivery of both of these formats, Cloudflare does not support the Vary header for paths without a file extension. Because of this, it is possible that if the WebP/AVIF version of a header is cached, that version may be served to browsers that cannot support such formats and could result in broken images for such users. The linked GitHub issue has a potential workaround, and we currently have a request in to Cloudflare to support such functionality.

Because Atlas does not rely on serverless functions/edge functions, such functionality currently runs on the origin Node server. It is important to note that this means that such functions will run only on requests that terminate at the origin; any requests served from the edge will continue to serve whatever response is cached at the edge for that path.

Visit the Faust.js documentationfor more in depth details on framework features.