Guide 01 · Developer docs

Choosing how to build

Decide where the pages of a Core dna site are composed before writing code: on the platform, in your own application, or on the platform with a few pieces filled in by the browser. The decision tree, each shape in depth, multi-brand and languages, and a table and case studies to make the call.

L2
Unit 06 · Making the choice

The decision table

Making the choice Page 27 of 29 Updated

Six questions to settle at a kickoff meeting, with what server-side, hybrid and headless each give on every one and a blank column for your project. Each verdict links to the page of this guide it rests on.

Who this is for. The technical lead or architect running a project kickoff, with the product owner in the room. After this page you can score a project on traffic, authoring, team skills, personalisation, commerce and SEO, and show the page each verdict comes from.

The table

Read across a row: each cell says what that shape gives or costs on that dimension, and links to the page of this guide it rests on. The first column holds the question to ask in the room. Write the answer, and the shape it favours, in the last column.

DimensionServer-sideHybridHeadlessYour project
Traffic profile
How many views come from signed-out visitors, and how sharp are the peaks?		A page rendered for a signed-out visitor is stored per hostname and path, for a day by default, and sent before any template runs. A CDN can sit in front.The same stored pages; only the per-visitor fragments are requested on every view.API responses are cached by your front end: its own cache and CDN carry the load.
Authoring needs
Do authors expect to edit on the page, and to preview a draft before publishing?		In-context editing and live preview are built in.Built in, as for server-side.In-place editing is given up; preview is a route you build and enter in the Alternative live preview url setting.
Team skills
Who will build the site, and who will maintain it after launch?		A template author in Smarty or Twig. Which engine is a separate decision.The same template author, plus a JavaScript developer who owns the fragments, the one client module and the bundle split.A front-end application team that also builds and maintains routing, preview, the sitemap, redirects, SEO tags and cache invalidation (the worksheet).
Personalisation
Does any part of a page differ by visitor: a signed-in name, a cart, recommendations?		A personal element inside a stored page shows one visitor's data to the next, and taking the page out of the cache renders every view from scratch (what one personal element does).The documented pattern: a bundle switched on in site data fetches the personal block as a fragment, with its parameters declared for the cache key (the bundle, what always needs a fragment).Your own application composes every view, so personalisation is part of it from the start (where composition happens).
Commerce
Is there a cart or a checkout, and do buyers sign in?		A cart count or a signed-in checkout is per-visitor, so a commerce site seldom stays server-side alone.A single-page checkout: state handed to the browser once, every call through one client module carrying the CSRF token, as in the course provider's study.The whole checkout interface is yours, built against the same commerce API.
SEO
How much traffic comes from search, and who maintains the SEO fields?		The template prints each record's SEO settings and the sitemap is generated (built in). A crawler is never signed in, so it gets the same stored page as any signed-out visitor.As for server-side: the crawler gets the stored page, before any personal fragment loads (where the platform hands off a request).The SEO data is in the API. Printing it, and building the sitemap with the same exclusions, is yours (SEO tags and the sitemap).
Commerce is the same engine in every shape

Prices, discounts, tax, checkout and payment are worked out by the platform whichever shape you choose (What the choice does not change). The commerce row decides where the checkout's interface lives, not how commerce works.

Filling it in at the kickoff

  1. Ask each row's question and write the answer in the last column in a few words, with the project's own numbers where you have them.
  2. Next to each answer, write the shape that row favours. Where a row favours headless, write down the reason too: When headless is right, and three wrong reasons lists the reasons that hold and three that do not.
  3. Where rows disagree, settle it with the decision tree. The question underneath every row is where each page is composed.
  4. For the shape you choose, start the estimate. Headless: copy the rows of the rebuild worksheet. Hybrid: list the per-visitor elements, because each becomes a fragment of its own.

Two decisions the table leaves out

  • The template engine. Smarty or Twig is independent of the shape, and is a separate decision. The engine is one setting for the whole site (Switching template engine).
  • Multi-brand. Serving several brands from one codebase combines with any of the three shapes, so it is an overlay, not a fourth column.
Go deeper
GuideWhere pages are composed: the decision tree GuideWhat a headless build must rebuild GuideFive case studies GuideMigration paths

Was this page helpful?

Your answer goes to the docs team.