How It Works

Every eddev page starts with WordPress. Even when the public frontend runs on Vercel, WordPress decides which route has been requested and which view should render it.

Route Resolution

For a normal page request, WordPress resolves the URL using its template hierarchy. Instead of ending at a PHP template, eddev can resolve that template to a React view such as front-page, page, single, single-{post-type}, archive-{post-type}, or 404.

After the view is known, the PHP runtime builds route data:

1. It runs the paired view GraphQL file when one exists.
2. It runs global app data when the request needs it.
3. It adds the matched view name, admin context, metadata, and query debug information when available.
4. It returns either JSON route data or an HTML response containing that route data.

The JSON shape is the contract between WordPress and the React app. React does not independently decide what URL maps to what content.

SSR Request Flow

In the usual production setup, public traffic goes to Vercel and WordPress lives on the WP Engine origin.

When Vercel receives a page request:

1. The eddev serverless app asks WordPress for the matching route payload.
2. WordPress resolves the route, runs the relevant GraphQL files, and returns the payload.
3. The serverless app renders the active React view inside the app shell.
4. The browser receives HTML with the page content already rendered.
5. React hydrates the page so routing, blocks, query hooks, and interactive components can run in the browser.

This keeps WordPress as the content and routing source of truth while giving the public site server-rendered HTML.

SPA Request Flow

SPA mode is what happens when the browser accesses the WordPress origin directly, such as a Local site or a WP Engine origin frontend.

In that mode, WordPress still resolves the same route and builds the same route payload. The difference is that the HTML response is an app shell with the route payload embedded for the browser. The browser loads the frontend bundle, reads the payload, loads the matching React view, and renders the page client-side.

SPA mode is useful for origin previews and WordPress-hosted fallback behavior, but it is not the preferred public production path for current projects.

Client Navigation And Data

After the first page load, eddev navigation fetches route payloads instead of full HTML pages.

In serverless mode, browser navigation asks the JavaScript frontend for route data, and the serverless app fetches or caches the matching WordPress payload. In WordPress-hosted SPA mode, the browser asks WordPress for the route payload directly.

Runtime GraphQL hooks use named data endpoints rather than exposing arbitrary GraphQL text from the browser. View, block, and app GraphQL files are part of route rendering; runtime query and mutation hooks are for browser-triggered data after the page is running.

For the details behind each part of this flow, see Views, Routing, GraphQL, and Serverless.