Felsoroltam három kategóriát, és fejben már a monolit kategóriánál jártam, de és/vagy lett volna indokolt. Jó is, hogy felhoztad mert egyáltalán nem triviális, hogy ezeket csak együtt lehet használni, ez gyakori félreértés.
Headless CMS önállóan, azaz SSG nélküli eset, abszolút működőképes. Ez a Single Page Application (SPA) modell. De hívják Client-Side Rendering, röviden CSR modellnek is.
A Headless CMS valahol fut egy szerveren, és csak az adatokat szolgáltatja api-n keresztül. A weboldal maga egy teljesen különálló projekt, ami lényegében csak egy index.html és egy nagy JavaScript csomag. Mivel a weboldal JavaScripttel megtömve ebben az esetben csak statikus fájlokból áll (index.html, app.js, style.css), ezért a világ legegyszerűbb és legolcsóbb tárhelyeire feltehető.
A Headless CMS-t egy "okos" szerverre kell tenned, aminek van adatbázisa is. Mondjuk DigitalOcean, Heroku, Render, vagy a saját VPS-ed, vagy nagy szolgáltatók, Google, Azure, Amazon.
A JavaScript Weboldal a Front-end. Ezt pedig egy buta, villámgyors statikus tárhelyre lehet küldeni Static Hostingra.
Netlify, Vercel, GitHub Pages, Cloudflare Pages, vagy AWS S3 ha luxi kell:)
A látogató beírja az URL-t. A böngészője letölti a statikus HTML/JS fájlokat mondjuk a Netlify-ról. A JavaScript a látogató user gépén fut le. Ez a JavaScript felhívja a Headless CMS API-t, hogy "Hé, add ide a szócikkeket!" A JavaScript megkapja az adatot, és letolja a tartalmat a user képernyőjére.
Hátránya, hogy a Google kereső csak egy üres oldalt lát, ami rossz a SEO-nak, de ez néha előny is lehet.
Az SSG is működhet önállóan Headless CMS. Sőt ez nemcsak működőképes, de ez az SSG-k eredeti és leggyakoribb felhasználási módja. Úgy működik, hogy amikor az SSG fut, nem egy külső API-hoz (Headless CMS) csatlakozik, hanem közvetlenül a projekt mappájában lévő text fájlokból olvassa be a tartalmat. A "tartalom" ebben az esetben: Markdown fájlok (.md), ahol minden egyes cikk, blogposzt, vagy oldal egy külön `.md` fájl a mondjuk a src/posts/ mappában. Json vagy yaml fájlok, adatlisták, beállítások pl. a menüpontok listája, a weboldal neve.
Ez a tökéletes modell például fejlesztői blogokhoz. Tudtommal a világ fejlesztői blogjainak 90%-a így készül. A fejlesztő megírja a posztot egy .md fájlban, git push-sal feltölti GitHubra, és a Netlify/Vercel automatikusan legenerálja a HTML-t. Vagy a dokumentációs oldalak sok esetben mind Markdown fájlokból generált oldalak. React, Vue, Astro dokumentációja mind ilyen. Szerintem egy kórház webportáljához is teljesen megfelelő.
Hihetetlenül gyors, biztonságos, és minden, kód és tartalom egy helyen van.
Hátránya, hogy a nem-tech usereknek nehezebb így tartalmat szerkesztenie. De erre lehet írni csak belső használatú publikáló szoftvert, illetve ott a Git-based CMS modellje.
És természetesen telepítesz egy Headless CMS-t, és megmondod az SSG-nek, hogy a Markdown fájlok helyett onnan olvassa az adatokat. Ilyenkor mindkét építőkockát együtt használod ÉS-sel.