Headless hosting workflows

# About headless mode

Headless PHP applications separate the backend from the frontend. They communicate through APIs rather than traditional server-rendered templates.

• The PHP backend - a framework like Laravel, Symfony, or headless a CMS like Craft CMS, Kirby, Statamic - exposes a RESTful API or GraphQL endpoints.
• The JS frontend - a frameworks like Vue.js, React, or Next.js - consumes this data to create dynamic user interfaces, often in form of Single Page Applications (SPA).

A headless setup is more sophisticated. It allows different frontends to share the same backend and supports separation of concerns.

# Hosting headless

Consider project requirements carefully before jumping into headless adventures. There are also some considerations when it comes to hosting headless web projects.

# Project organization

One thing to decide, is how the hosting will be organized. Two independent systems can be deployed separately or together:

# 1 - Separated hosting

This is the more professional and the often propagated mode. The backend is hosted with a PHP server, hopefully fortrabbit. The frontend is hosted at a JAM Stack hosting service, like Netlify or Vercel.

# 2 - Coupled hosting

It's also possible to have both systems run side by side in one environment at fortrabbit. This has the benefit that the project code base can stay together (maybe in a single repo) and does not have to be separated over two different hosting systems.

See the project organization for more options.

# SEO considerations

Some web projects require to be indexed by search engines. That's something classical SPAs are not good at by definition. Here are the most common approaches:

# CSR - Client Side Rendered

HTML is only created in the browser (classic). This is OK for any web application that will users to login.

# SSG - Server Side Generated

HTML is getting created during deployment for all pages. This is similar to classical static page generators like Jekyll. But when a human visits, first the static page is going to be loaded and then replaced by dynamic parts, so that any further interaction can be handled through smaller AJAX calls.

But what happens, when an editor changes the content of an article? The generation of the pages only happens when the project get's deployed, not on edit. Deploy webhooks (after edit) and incremental builds are aiming to help. But setting that up can be challenging.

# SSR - Server Side Rendered

HTML can also be live server side rendered. This is not easily available for fully decoupled headless systems. There are some approaches to couple frontend and backend as modern monoliths.

# ISR - Incremental Static Regeneration

Incremental Static Regeneration (ISR) addresses shortcomings of SSR and SSG by serving the existing static page to the first visitor of an outdated route, hydrating it once the dynamic content loads, regenerating the static version in the background, and then delivering the updated page to subsequent visitors.

This of course also requires two servers to host one website: Backend server provides the API; Frontend server creates new static pages on the fly.

The frontend however can still be hosted on the edge. It's good for SEO and it is fast. But it's more complex to setup too. It's also not the cheapest option.

# Performance

Headless apps, specifically in SSR mode, can cause considerable server load peaks. Imagine a large website that always needs to be completely rebuild every time it get's deployed. Maybe generating thousands of pages with complicated queries and a lot of images. For the server that means, short times of high performance and long periods of idle time.

In our experience GraphQL can also be dangerous. It is a powerful tool to query any content from the backend. It's also very easy to write query that do not perform well. Under certain configuration, specifically with larger data sets, this can lead to performance issues.