Who this is for. Anyone about to skip half of these guides because the project is headless, or because it is not. After this page you know which parts of the platform work identically in every shape, which guides to read whatever you chose, and the few things the choice really changes.
What works the same in every shape
| Part of the platform | Why it does not depend on the shape | Guide |
|---|---|---|
| Layouts, areas, input types and components | They are the content model. A template reads an area with getAreaText; a headless front end reads the same area through the API, as areaText(name) in a properties selector | Guide 4 |
| Pages, blogs, books, FAQs and custom entities, with their revisions, publishing and scheduling | The records and their life cycle are the same whoever displays them | Guide 5 |
| Jobs (formerly hooks) | A job's entity events fire when a record is created, updated or deleted, whether the change came from the admin or the API, and its actions run on the platform | Guide 9 |
| Members, groups and permissions | Accounts belong to the client, not to a front end; signing in works through the site's login page or the API's login route | Guide 7 |
| Forms | A form is defined in the admin and its submissions are stored and acted on by the platform, whether the form is rendered by a template or posted through the API | Guide 10 |
| Carts, checkout, payments and orders | Prices, discounts, tax and payment are worked out by the platform; the cart and checkout routes of the API are open to visitors for exactly this reason | Guide 8 |
| Search | The index and its views are the platform's, rendered by a template or read through the API | Guide 11 |
| Images | Resizing and conversion are URL parameters on the image's address, which any front end can use | Image URL parameters |
This is the practical point of the page: the guides on content modelling, content types, members, commerce, jobs, forms and search are worth reading whichever shape you choose.
What the choice does change
- Who renders. Your templates, or your application.
- Who routes. The platform maps paths to records and applies the rewrites editors enter, but only for the pages it renders itself.
- Who caches. The page cache stores pages the platform renders. Nothing the API returns is stored in it.
- Who previews. The admin's live preview renders the record through your templates; a headless front end has to provide a preview of its own.
- Who the request runs as. A template renders for whoever is visiting, and a visitor or a signed-in member never sees an unpublished record. A headless front end's server calls the API as a backend user, which on a default site does see unpublished records in lists. The same request answers differently, which is why drafts need care in a headless build.
What to read, by shape
| Guides | Server-side | Hybrid | Headless |
|---|---|---|---|
| 4, 5, 7, 8, 9, 10, 11: the content model, members, commerce, jobs, forms and search | Yes | Yes | Yes |
| 2 and 3: template languages and the theme repo | Yes | Yes | Guide 2 for the templates the platform still renders, such as those inside jobs |
| 6: the APIs | For integrations | Yes | Yes |
| 12: caching and deployment | Yes | Yes | The deployment and go-live parts; the page cache does not serve your pages |