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
  • Decoupled Mode
  • Embedded Mode

Was this helpful?

Architecture

Previous9. StylesNextDecoupled Mode

Last updated 3 years ago

Was this helpful?

In Frontity projects, WordPress is used as a . Frontity uses data from the WP REST-API and generates the final HTML that is displayed in the browser using React. This means that WordPress is merely used for managing the content.

A Frontity project will always require two servers:

  1. A WordPress Server (PHP), either:

    • An Apache or Nginx web server running PHP

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

  2. A Frontity Server (Node.js), either:

    • A server running Node.js

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

There are then two main (architectures or configurations) that can be used to implement Frontity projects:

Depending on the mode used, the main domain (e.g. www.domain.com) will be connected either to the Wordpress/PHP Server (in Embedded mode) or to the Frontity/Node.js server (in Decoupled mode). The main domain is the one used by site visitors to access the HTML of the site.

The other server will get a secondary role and its domain can be either a separate domain (e.g. project-d418mhwf5.vercel.app) or a sub-domain of the main domain (e.g. wp.domain.com).

Both of the two possible Frontity architectures (i.e. Decoupled or Embedded Mode) feature:

  • A similar distribution of functionality across the servers

    • WordPress is used as a CMS - to manage the content

    • Frontity is responsible for the presentation

  • A similar operation

    • Frontity fetches the data from the WordPress REST API

    • Frontity generates the final HTML as an React App

Both of these architectures (or modes) require two different servers with two different URLs but the communication workflow between these two servers differs in each case.

Decoupled Mode

Embedded Mode

Decoupled Mode

  • It uses two domains, one for WordPress and another for Frontity.

In this mode site visitors access the site using the main domain and are served HTML pages directly from Frontity, and 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.

Decoupled mode needs no additional structural elements, such as plugins.

Embedded Mode

  • The secondary domain (which can be a subdomain of the main domain) points to Frontity.

  • All the requests are handled by WordPress. No reverse proxy is needed.

  • The PHP theme is replaced with an internal HTTP request to the Frontity server.

  • Other WordPress URLs (i.e. those not handled by Frontity) work normally.

In Embedded mode the main domain points to the WordPress installation, and the secondary domain points to the node.js server running Frontity. In this mode both site visitors and content editors use the same domain, i.e. the main domain, to either visit the site or access the admin pages. The secondary domain is never directly accessed.

Since, in embedded mode, the Frontity site is never directly accessed the secondary domain can be anything - including free domains allocated by the node.js hosting service.

Implementing a in Frontity projects is highly recommended to improve response times. A is especially recommended to cache REST API requests in both architectures.

is implemented as follows:

The main domain () points to Frontity.

A secondary domain (which can be a subdomain such as ) points to WordPress.

is implemented as follows:

The main domain () points to WordPress.

Embedded mode requires the . This plugin replaces the WordPress theme with its own template file which fetches the HTML from the Frontity server.

๐Ÿ—๏ธ
headless CMS
Frontity Modes
Decoupled mode
Embedded mode
Isomorphic
caching strategy
WordPress Cache plugin
Decoupled mode
www.domain.com
wp.domain.com
Embedded Mode
www.domain.com
Frontity Embedded Mode plugin