Inline App Server

What "Same Origin" Buys You

When the static files for a React app and the API endpoints it calls are both reachable under the same scheme+host+port — for example, everything under https://qa.grippingly.com — the browser treats every request as same-origin. Same-origin requests:

• Need no CORS configuration. The browser's cross-origin protections simply don't apply — same-origin requests were never restricted in the first place.
• Can use relative paths. A fetch to /api/v1/... from a page loaded at https://qa.grippingly.com/flowstudio/ automatically resolves against that page's own origin — the browser fills in the scheme and host for you.
• Work identically on every same-origin deployment. Because nothing about the request depends on a specific hardcoded hostname, the exact same compiled bundle behaves correctly whether it's reached via qa.grippingly.com, staging.grippingly.com, or grippingly.com — see Chapter 2.4 for exactly how that resolution works.

How It's Typically Wired

"Inline" doesn't necessarily mean the API server process itself serves the static files (though it can) — the important part is that requests to the React app's HTML/JS/CSS and requests to the API's endpoints both terminate at the same public origin. Common ways to achieve that:

• The API server hosts the compiled dist/ folder as static files, alongside its own /api/* routes.
• A reverse proxy (nginx, YARP, IIS, etc.) sits in front of both the API process and a static file host, and routes by path — e.g. /api/* to the API, everything else to the React app's static files — while presenting one public hostname.

One public origin, two things behind it. The browser never needs to know they're separate processes.

What This Means for Configuration