Who this is for. Anyone about to start a build, and above all whoever decides its shape. After this page you will know the two ways a Core dna site is built, what the common hybrid between them looks like, and where to make the decision properly.
Server-side templating
The platform builds every page. A request arrives, the platform finds the record at that URL, and the record's layout names the template that renders it. You write the templates in Smarty or Twig, whichever engine the site uses, and the platform sends the finished HTML.
What comes with it: a page cache that can answer a request without running any template, URLs that follow the page tree, editors who see their work on the real site, and no second application to host. What it asks of you: a cached page is the same for every visitor, so anything that depends on who is looking, such as a cart count or a signed-in name, is either filled in by the browser or left out of the cached page. Most Core dna sites are built this way.
Headless
An application of your own, such as a Next.js site or a mobile app, composes the pages. It reads content from the REST or GraphQL API, and the platform renders no HTML for it. Editors still model and enter content in the admin, through layouts and areas, and the API returns what they entered.
What it asks of you: you host and run that application, and it calls the API from its server with a credential, an OAuth access token by preference or an API key. A page in a browser on another origin cannot read the API's answers, because the platform sends no cross-origin headers. Everything the platform would have done for a page, from routing to page caching and the sitemap, becomes yours to build.
Hybrid, the common middle
Most sites land in between: pages rendered on the server from templates, with a few interactive parts that the browser fills in by calling the same site. A cart count, a search box with instant results, or a form that submits without reloading the page are typical. Because the browser is on the site's own origin, it can call the routes visitors are meant to reach, such as the cart, checkout and form submission, and custom endpoints you define as jobs for anything else.
Deciding
| If… | It points towards |
|---|---|
| Most pages are the same for every visitor | Server-side templating, served from the page cache |
| A few parts of the page belong to the visitor: a cart, a signed-in state | Hybrid |
| The same content must reach a mobile app as well as the website | Headless for the app; the website can still be server-rendered |
| A front-end application already exists and will stay | Headless |
This is a sketch, not the decision. Choosing how to build is the guide to read before you commit, with the trade-offs in full and worked cases; it is one of the three guides The twelve guides marks as required.