Demo Site: don't exclude middleware for /api/... requests

[nsams]

alternative to vivid-planet/comet-starter#622

This PR moves the api routes from src/app/api into src/app/[domain]/api.

• The api requests are technically located under a specific domain (host) like any other page, so it is not wrong to have a domain param
• the currently implemented api routes don't use the domain param though (other apis might need it)
• this solves errors rendering not-found in /api/..., as the not-found page accesses the domain param (main motivation for this change)

[fraxachun]

How does this work with the preview domain?

[nsams]

How does this work with the preview domain?

it doesn't.

Ideas to fix this:

• exclude /api/site-preview from middleware (and move it back into /src/app/api/)
• look for /api/site-preview in https://github.com/vivid-planet/comet/blob/main/demo/site/src/middleware/sitePreview.ts#L11

any other ideas?

Is it generally a better idea than your fix?

[fraxachun]

Is it generally a better idea than your fix?

Yes, I think so.

What about:

• Moving /api/site-preview to just /site-preview (just like we also have /block-preview at the same level) and handle it in the same way as the block-preview?
• Handle /api/status also in a middleware?

So we get rid of the /api folder.

I could make a PR for that.

[nsams]

Moving /api/site-preview to just /site-preview (just like we also have /block-preview at the same level) and handle it in the same way as the block-preview?

yes, that would work - and the /api in the url is not really neccasary. I'll do that in this PR.

So we get rid of the /api folder.

I would not try to do that, having different /api routes is quite common. (for example in "a recent big customer project version 7" we have 6 api routes (+status and site-preview))

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[fraxachun]

So we get rid of the /api folder.

I would not try to do that, having different /api routes is quite common. (for example in "a recent big customer project version 7" we have 6 api routes (+status and site-preview))

Next.js suggest having api folders co-located to the page it is used (https://nextjs.org/docs/app/building-your-application/routing/route-handlers), this has several advantages (see also #2987). So I'm not convinced keeping /api as best practice.

[nsams]

while I fully support co-located api, this is especially for our use cases often not possible:

• if the api is used inside something that is under the [[...path]] page
• if the api is used at multiple places
• if the api is used in a layout (eg for loading the menu)

[fraxachun]

while I fully support co-located api, this is especially for our use cases often not possible:

Convinced. I'll update vivid-planet/comet-starter#622 according to this PR.