Who this is for. Anyone who has to explain the choice to a client or a team. After this page you can describe each shape in a sentence, point to a real site built that way, and say why a multi-brand site is not a fourth option.
| Shape | Who composes the page | What the platform sends | Read |
|---|---|---|---|
| Headless | Your own application | Data, over the API | Unit 2 |
| Server-side templating | The platform, from your Smarty or Twig templates | Finished HTML, from the page cache when it can | Unit 3 |
| Hybrid | The platform, with a few parts added by the browser | Cached HTML, and the per-visitor parts on request | Unit 4 |
Headless in a paragraph
An application you run elsewhere, such as a Next.js site or a mobile app, owns the front end. The platform serves content and commerce through three surfaces: the REST API for every record and every write, the GraphQL API for shaped reads, and custom endpoints built in the admin as jobs with a web event. Editors still model and enter content in the admin, through layouts and areas. None of the production sites studied for this guide is headless; the nearest are islands such as a single-page checkout that talks to the checkout API. The trade-offs are larger than teams expect: routing, preview, the sitemap, redirects, error pages and cache invalidation become your code, and a backend credential reads unpublished records unless every request says otherwise (What a headless build must rebuild).
Server-side templating in a paragraph
The platform composes every page. A request arrives, the platform finds the record at that path, the record's layout names a template, and your template renders it, in Smarty or in Twig. Both engines run real sites: an online course provider with a shop and a touring company are written in Smarty, and a group of twelve brand sites shares one Twig template set. The engines are peers, not a default and an alternative. The platform routes, caches, previews and hands templates the same variables whichever one a site uses; what differs is the syntax, the helpers each engine registers, and the rules on what a template may call. A site uses one engine for all its templates. Smarty and Twig are peers says more, and Guide 2 covers the choice.
Hybrid in a paragraph
A server-rendered page, cached by the platform, with islands of JavaScript that fetch what differs per visitor: the cart count, the signed-in state, a recommendation block, a checkout that talks to the API. This is where most Core dna projects end up, whether or not they planned to: both production sites studied for this guide that have a member area work this way. Planning for it costs nothing. Keep the per-visitor parts out of the cached page from the first template, and the rest of the site stays cacheable (Hybrid, the common case).
Multi-brand as an overlay
One codebase serving several brands, regions or languages combines with any of the three shapes rather than competing with them. The Twig group above is server-side and multi-brand: twelve sites, each brand's differences in a folder of its own. The touring company is hybrid and serves two brands from one site, each brand on an environment of its own. The first decision is structural, several hostnames on one site or several sites, and it is expensive to reverse (Multi-brand and multi-language).