Frontity Docs
  • ยป Welcome to Frontity
  • ๐Ÿš€Getting started
    • Quick start guide
  • ๐Ÿ“ƒAbout Frontity
    • Frontity features
    • Browser support
    • Get involved
  • ๐Ÿ“šCore Concepts
    • 1. Project
    • 2. Settings
    • 3. Packages
    • 4. Roots
    • 5. State
    • 6. Actions
    • 7. Libraries
    • 8. Namespaces
    • 9. Styles
  • ๐Ÿ—๏ธArchitecture
    • Decoupled Mode
    • Embedded Mode
  • ๐ŸŒŽDeployment
    • Deploy Frontity using Vercel
    • Deploy Frontity on Layer0
    • Deploy Frontity on Heroku
  • ๐ŸŒ—Isomorphic React
  • โšก๏ธ Perfomance
    • Caching
    • Link prefetching
    • Lazy Loading
    • Code Splitting
  • ๐Ÿ”ŽSEO
  • ๐Ÿ“–Guides
    • Setting the URL of the WordPress data source
    • Using Environment Variables in a Frontity project
    • WordPress requirements for Frontity
    • URLs in a Migration from WordPress to Frontity Decoupled Mode
    • Frontity Query Options
    • Redirections with Frontity
    • Understanding a Frontity project
    • Add a new Frontity package or theme to your project
    • How to share your Frontity project
    • Understanding Mars Theme
    • Working with processors
    • How to process page-builder content in Frontity
    • Keep Frontity Updated
    • Troubleshooting
    • JavaScript
    • React
  • ๐Ÿ‘Contributing
    • How to contribute?
    • Contributing Guide
Powered by GitBook
On this page
  • Table of Contents
  • Features of the Decoupled Mode
  • Technical considerations
  • Caching in Decoupled Mode

Was this helpful?

  1. Architecture

Decoupled Mode

PreviousArchitectureNextEmbedded Mode

Last updated 3 years ago

Was this helpful?

In Decoupled mode the primary domain points to the Node.js server hosting Frontity. This is the site that visitors access directly in order to view the content.

Frontity will fetch the data from the REST API of the WordPress Server and will return the final HTML as an React App.

Any Frontity architecture requires two servers. In Decoupled Mode you need to have:

  • A main domain pointing to the Frontity Server, either:

    • A server running Node.js

    • A hosted function-as-a-service (FaaS) platform allowing serverless computing, such as AWS Lambda or Netlify functions

  • A secondary URL (or subdomain) pointing to the WordPress Server, either:

    • An Apache or Nginx web server running PHP

    • A hosted software-as-a-service (SaaS) platform with WordPress, such as WordPress.com

In this mode site visitors access the site using the primary domain and are served HTML pages directly from Frontity. The secondary domain is used by content editors to access the WordPress admin pages.

Frontity fetches data from the REST API located on the secondary domain, i.e. the WordPress installation, and uses that information to generate the HTML that is returned to the user.

Table of Contents

Features of the Decoupled Mode

The Decoupled Mode offers a number of advantages:

  • No extra WordPress plugin is required for this mode

  • It has the fastest workflow to respond to the requests: just a single call in SSR is made to the WP REST API, with no round-robin request for content and return of HTML.

  • It provides an extra layer of security as the WordPress site is not on the public-facing domain.

Technical considerations

Due to the two-domains nature of this mode, in Decoupled Mode e developers need to be aware of, test, and take care of many things that are normally handled for you by WordPress. For example:

  • Cross-domain 301 redirections from Frontity to WordPress and vice-versa.

  • 301 redirections of individual URLs stored in the WordPress database.

Additionally, in Decoupled Mode it is impossible to replicate the editing experience that content editors may be used to because in this mode itโ€™s not possible to:

  • Render the admin bar for logged in users.

  • Make 100% transparent post previews.

Caching in Decoupled Mode

In Decoupled Mode, the main domain is connected to the Node.js server executing the Frontity app which will process the URL requests to return the proper HTML based on the data from the WP REST API.

In this mode there are two types of requests that can be cached to minimize the computing time and to take advantage of the proximity of CDN servers:

The state.source.url property set in the frontity.settings.js file .

Decoupled Mode uses two different domains. The main one () for Frontity and a subdomain () for WordPress.

URL replacements from to . (see the โ˜๏ธ hint below)

Proxying WordPress resources that need to be served from the domain.

Adding CORS headers in the domain.

Purging page cache of the domain.

โ˜๏ธ In the guide you can learn more about why you need to change these URLs in the content of your WordPress site. The guide also provides useful information on how to do so.

With a good your Frontity project can be just as performant as a static site.

๐Ÿ—๏ธ
configures the URL of the WordPress installation
www.domain.com
wp.domain.com
wp.domain.com
www.domain.com
www.domain.com
wp.domain.com
www.domain.com
URLs in a Migration from WordPress to Frontity Decoupled Mode
caching strategy
Features of the Decoupled Mode
Technical considerations
Caching in Decoupled Mode
Isomorphic
CDN for caching URL requests made to Frontity
Server caching for REST API requests in WordPress servers