Headless in front

What headless actually buys you

“Headless” is one of those words that has been used to mean six different things. Here it means something specific and narrow: the thing that renders the public site has no editing interface, no admin login, and no database connection. It is a renderer. You give it content files, it gives you pages.

That sounds like a limitation. It is the opposite. Because the front end has no private surface, there is nothing on the public site to attack, nothing to keep patched, and no session to hijack. The public site is pages. That is all it is.

The front end is built with Astro, and rendered server-side rather than baked into static files ahead of time. That combination is worth explaining, because the obvious choice for a personal site is static generation and I deliberately did not use it.

Why server-rendered, not pre-built

Static generation writes every page to disk at build time. It is fast, cheap and simple, and for a lot of sites it is the right answer.

It stops being the right answer the moment routes need to be resolved rather than enumerated. A book has a chapter route. A deck has a slug route. A category page exists only if something is in that category. With static generation, every one of those has to be listed at build time, and the list has to be regenerated whenever content changes.

Server rendering moves that decision to request time. The route is resolved when someone asks for it. Adding a book adds its pages; removing one removes them; no build-time enumeration to keep in sync.

The cost is that a server has to be there to do the resolving. Which brings us to where this actually runs.

Where it runs

The rendered site is deployed to Wix’s hosting platform, through an adapter that packages the server-rendered output into something their edge can execute.

That combination surprises people, so it is worth being plain about it: Wix here is infrastructure, not a website builder. None of the site’s pages are built in a Wix editor. Nothing is dragged onto a canvas. The platform receives a built bundle and serves it from a CDN. It could be swapped for another host without changing a line of the site’s own code — the adapter is the only piece that knows where it is going.

What that gets me: a global CDN, TLS, a custom domain, and no server to administer. What it costs: one adapter dependency, and a small number of platform behaviours to work around. The most notable is that the platform serves its own robots.txt at the edge, which is why discovery needed its own approach — covered in its own chapter later.

The front end’s whole job

Reduced to its essentials, the public front end does five things:

1. Reads content from the content store — articles, books, decks, site configuration.
2. Resolves a route — which article, which chapter, which slide deck.
3. Renders a page — layout, typography, navigation, the reading furniture.
4. Emits metadata — canonical URL, social card tags, structured discovery files.
5. Refuses to show anything unfinished — the draft rule, which gets its own treatment in the publishing chapter.

Nothing about editing. Nothing about authentication. Nothing about uploads. All of that lives on the other side of the wall, and the next chapter is about the wall itself.