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 Embedded Mode
  • Technical considerations
  • Caching in Embedded Mode

Was this helpful?

  1. Architecture

Embedded Mode

PreviousDecoupled ModeNextDeployment

Last updated 3 years ago

Was this helpful?

In Embedded Mode the primary domain points to the WordPress server. This is the URL that visitors access directly in order to view the content.

WordPress (via the ) will redirect the request to Frontity, which will get the data from the REST API to return the final HTML as an React App that will be returned to the user by WordPress.

Any . In Embedded Mode you need to have:

  • A main domain 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 (only plans allowing plugin installation)

  • A secondary URL (or subdomain) 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

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 WordPress admin pages. The Frontity server on the secondary domain is never directly accessed.

Table of Contents

Features of the Embedded Mode

Embedded Mode offers several advantages over Decoupled Mode.

  • The WordPress site exists under the primary domain, thus ensuring that:

    • all the SEO benefits already built-in to WordPress work as normal

    • existing SEO (for a site transitioning to Frontity) will not be affected

    • sitemaps generated by WordPress/Yoast/All-in-one-SEO work as normal

    • WordPress page cache plugins and hosting CDNs continue to work as normal

  • Content producers/editors continue to have the same experience

    • post/page preview remains available

    • the admin bar is active for logged in users

In addition, since the Frontity site is never directly accessed the secondary domain can be anything - including free domains allocated by the node.js hosting service - so there is no need to purchase an additional domain or configure DNS settings for sub-domains.

But there are some things that should be taken into account when using Embedded Mode:

  • It will not work with free wordpress.com plans as the installation of a plugin is required.

  • More routing is involved (resulting in potentially slower execution than Decoupled Mode) with the "two stage round trip" (WordPress โ†’ Frontity โ†’ WP REST API โ†’ Frontity โ†’ WordPress), so a caching strategy is a necessity rather than simply a nice to have.

Technical considerations

  • URL replacements

  • Cross-domain 301 redirections

  • CORS headers

  • Purge page cache

  • Proxy WordPress resources from the Frontity server

  • WordPress posts 301 redirections

  • Maintain the reverse proxy configuration

These are all either unnecessary (in the case of URL replacements), or continue to be handled by WordPress.

In this mode content editors continue to have the same editing experience:

  • The admin bar is visible for logged in users.

  • Post previews work just the same as in a normal (non-headless) WordPress installation.

Caching in Embedded Mode

In Embedded Mode the main domain is connected to the WordPress server which will use a custom template (provided by the plugin) to redirect to the Frontity Web Server in order to get the proper HTML based on the data of the WP REST API.

In this model the following cache layers are highly recommended:

As there is more routing involved in Embedded Mode (WordPress makes a call to Frontity, which makes a request to the WP REST API, which then returns the JSON to Frontity, and which then returns the HTML to WordPress) a caching plugin for the HTML (caching the URL requests) is a necessity rather than simply a nice to have.

This mode requires the installation, activation and configuration of the to work.

The required by this mode, replaces the WordPress theme with its own template file which fetches the HTML from the Frontity server. However, before Frontity can deliver the HTML it must request the content from the WordPress REST API, necessitating a two stage round trip.

Due to the "two stage round trip", is therefore a necessity in this architecture to ensure that site performance is optimal.

In this mode, a solution to host the Frontity server is especially recommended as it will make it cheap, easy and infinitely scalable.

It requires an additional plugin, namely the .

WordPress still needs to go through it's on initial page load

Due to the one-domain nature of this mode and the fact that the routing is managed by WordPress, developers donโ€™t need to take care of any of the issues mentioned on the page, including:

In order to access post previews from the REST API revisions need to be activated. You can read more about revisions on the . And if you are using custom post types, remember to when you register them.

๐Ÿ—๏ธ
Frontity embedded mode plugin
Frontity Embedded Mode plugin
serverless
Frontity embedded mode plugin
bootstrap process
official WordPress docs
add support for revisions
caching
Features of the Embedded Mode
Technical considerations
Caching in Embedded Mode
Frontity Embedded Mode plugin
Isomorphic
Frontity architecture requires 2 servers
Decoupled Mode
CDN for caching URL requests made to WordPress
Server caching for URL requests in WordPress servers
Server caching for REST API requests in WordPress servers