Website rebuild

[vronk]

Using NextJS framework the DARIAH website will be built server-side upon every content update commit.

With expected many small edits, this sounds like an inappropriate burden on the deployment pipeline.

Especially, the population of the index must be a separate pipeline with its own schedule.

Are these assumptions correct
and are there any suggested remedies?
(We were discussing an option for an article preview?)

[vronk]

@stefanprobst, maybe you could comment, if I understand it correctly.

[stefanprobst]

next.js, like other modern javascript frameworks, supports different rendering strategies, which can be set granularly per route or even per component.

it is possible, but not necessary, to prerender content at build time, but it is also possible to do it at request time.

both approaches have different performance characteristics: prerendering at build time means longer build times, but quick server responses, because all the work has already been done upfront. request-time rendering means shorter build times but the server has more to do when serving a request (fetch content and render page).

both approaches also have different infrastructure requirements, as you noted: prerendering at build time means any content change requires a new deployment, while rendering at request-time means just an api call to a headless cms. however, with caching, re-building should generally be quick enough - but will also depend on deployment infra. some numbers: content changes on dariah campus trigger a rebuild which takes between 3 and 4 minutes on vercel.

when storing content directly in git, and not in a dedicated cms, also consider that "fetching content via api call" means talking to the public github api.

"article previews": with request-time rendering it means dispatching a different api request when in preview mode. with static prerendering, it means switching the rendering strategy to request-time render instead of serving static prerendered content. both are possible with next.js.