Joomla and Next.js: Headless Without Losing the ACL

Joomla is usually left out of the headless conversation, which is out of date. Joomla 4 shipped a Web Services API in core - articles, categories, users, with token authentication - and Joomla 5 built on it. That is a REST API maintained as part of the platform rather than an extension somebody has to keep alive, and it makes this a real architecture rather than a clever idea.

What is worth keeping

Two things, and they are the reason this pairing is interesting rather than arbitrary.

The access control. Joomla's ACL is granular in core: groups, access levels, per-action permissions down to individual items. If you have a real editorial hierarchy - contributors, reviewers, departments that may only touch their own section - that model is already built and it is expensive to reproduce anywhere else.

The multilingual setup. Native, with associations between translated items, and not a plugin. Anybody who has assembled the same thing out of parts elsewhere knows what that is worth.

Both survive the front end moving. That is the point of doing it this way.

What changes, and what you have to design

The rendering moves, so the rendering model is what to understand first. Which routes are static, which revalidate on a publish, which have to be dynamic because they depend on who is asking.

Two things need explicit design rather than assumption.

View-level permissions. The ACL still decides who may edit. Who may see a given item now has to be honoured by the front end as well, so that logic exists in two places and they have to agree. Decide where the check happens and write it down.

Language routing. The associations come through the API, and the front end maps them onto its own routes. Deriving hreflang from those associations rather than from a list in a config file is what stops the site advertising translations that do not exist - which is the most common way this goes wrong.

What it costs

The template editing experience. Module positions, the menu manager, arranging things without a developer. Some of it comes back through how the front end is built, and it is a conversation to have with editors before the project rather than after.

Preview. The thing that decides whether editors keep trusting the system. If a draft cannot be seen as it will actually appear, the project is judged a failure for reasons unrelated to rendering. It is the specific failure mode of every headless CMS project, not a Joomla one.

Extensions that render. Anything that worked by outputting HTML into a template stops applying. Each becomes a decision: reimplement against the API, replace, or drop deliberately.

When to leave the template alone

If the site is articles and pages, and the template is doing its job, the cheaper wins are elsewhere. Images, fonts, the scripts that accumulated. Those are usually the whole of a slow page and they cost a week rather than a project.

Headless earns its place when the front end has to be more than a template: an application area behind a login, a design system shared with a product, or rendering behaviour the template cannot express. Until then, a Joomla site with a maintained template and a working ACL is a site in good shape, and there is no prize for replacing it.

Most sites asking this are on WordPress rather than Joomla, and the trade is worse there, because the access control and the multilingual handling are not already built. That comparison is here.