Skip to content

Commit

Permalink
ADR 59: Incremental static regeneration
Browse files Browse the repository at this point in the history
A quick ADR to describe the consequences of static project page builds, from Engaging Crowds.
  • Loading branch information
eatyourgreens committed Jan 19, 2024
1 parent 1d3f19c commit eec7894
Show file tree
Hide file tree
Showing 2 changed files with 19 additions and 0 deletions.
1 change: 1 addition & 0 deletions docs/arch/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -58,3 +58,4 @@
- [ADR 56: Use markdownz to parse markdown](adr-56.md)
- [ADR 57: Build @zooniverse/classifier and @zooniverse/react-components as ES modules](adr-57.md)
- [ADR 58: Internationalisation with the Panoptes translations API](adr-58.md)
- [ADR 59: Incremental Static Regeneration of project pages](adr-59.md)
18 changes: 18 additions & 0 deletions docs/arch/adr-59.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
# ADR 58: Incremental Static Regeneration for project pages

## Status
Accepted

## Context
When the first Engaging Crowds projects launched, project pages were built dynamically with `getServerSideProps`. Page builds were slow, with pages sometimes taking several seconds to load in the browser ([#2741](https://github.com/zooniverse/front-end-monorepo/issues/2741).)

## Decision
Use [Incremental Static Regeneration](https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration) (ISR) to build project pages. ISR is a feature of Next.js, which allows page HTML and JSON to be built and cached on demand, then served with `stale-while-revalidate` cache contol headers. While a page is building, visitors will get stale, cached content, resulting in a faster experience.

## Consequences
- Page builds were switched from `getServerSideProps` to `getStaticProps`, with a revalidation time of 60s. Revalidation can be set individually for each page route.
- `getStaticProps` can still be slow, when it runs, so data-fetching from the Panoptes API may need further optimisation ([#3341](https://github.com/zooniverse/front-end-monorepo/issues/3341).)
- Production projects and staging projects each have their own static routes: `/production/:owner/:project` and `/staging/:owner/:project`. Next.js middleware rewrites incoming request URLs to the production and staging routes used by the project app eg. https://fe-project.preview.zooniverse.org/projects/production/nora-dot-eisner/planet-hunters-tess
- API data isn't cached across page routes, so navigating between project pages will refetch the project and workflows etc. from the Panoptes API.
- When navigating between subjects, in a project that has page routes for individual subjects, `getStaticProps` is run for every subject. We worked around this by [shallow routing](https://nextjs.org/docs/pages/building-your-application/routing/linking-and-navigating#shallow-routing) client-side subject navigation, when the Done button is pressed. A better solution might be server-side caching of Panoptes API data across page routes, to avoid redundant computing of existing page props for each new subject.

0 comments on commit eec7894

Please sign in to comment.