FireUX · 2 min

Thin Nuxt Pages, Domain-Owned Product Logic

Keep Nuxt pages and API handlers focused on framework boundaries while domain capabilities own validation, policy and product behaviour.

Thin Nuxt Pages, Domain-Owned Product Logic

Thin Nuxt Pages, Domain-Owned Product Logic

Nuxt pages and server routes are important, but importance does not require them to contain the whole product.

A page is excellent at reading route state, setting page metadata and composing the interface. An API handler is excellent at receiving a request and returning an HTTP response. When either becomes the permanent home of domain policy, validation and data interpretation, ownership becomes difficult to see.

Treat framework files as adapters

A page about a User can remain in Nuxt’s pages directory while delegating the User’s meaningful behaviour to User-owned components and composables.

Similarly, an API endpoint can remain under server/api while delegating authorization, validation and commands to the domain that owns the record.

The direction becomes:

framework entrypoint → domain capability → shared mechanism

That dependency is easier to inspect than a page importing database clients, permission helpers, formatting rules and mutation logic directly.

Thin does not mean empty

The page still owns page responsibilities:

  • route parameters and navigation;
  • layout and page composition;
  • status and SEO integration;
  • selecting the correct domain presenter.

The API handler still owns HTTP responsibilities:

  • parsing the request boundary;
  • returning the correct response and status;
  • mapping trusted transport into a domain command.

The goal is not fewer lines at any cost. The goal is a visible boundary between framework concerns and product authority.

Why it helps maintenance

Domain-owned logic can be reused by another page, Console or trusted tool without copying route-specific code. It can be tested without simulating an entire page. Most importantly, security and product language remain attached to the records they describe.

This also narrows AI-assisted changes. An agent can inspect one complete capability rather than inferring behaviour from several distant entrypoints.

What we do at FireUX

FireUX keeps Nuxt framework entrypoints where Nuxt expects them. Substantial Entities extend the familiar technical spine with their own components, composables, models and server capabilities. Pages and endpoints delegate inward rather than becoming alternate owners.

Read what we learned about extending the Nuxt spine for the filesystem side of this decision.

Thin entrypoints are not an aesthetic rule. They make the ownership of real product behaviour easier for people and coding agents to find, change and verify.