Skip to content

Serve the FSE snapshot from a runtime cache instead of the build #134

Description

@kuuak

Parent

#132

What to build

Make the frontend read the FSE snapshot from a runtime cache instead of from a file baked into the build.

Today the snapshot is a build artifact imported statically, so it is inlined into the compiled server bundle — a template edited in WordPress cannot reach the frontend without a full rebuild and redeploy, and the build itself fails soft (shipping a site with no templates) whenever WordPress is unreachable.

After this ticket the snapshot is fetched on demand and held in Next.js' cache under a cache tag, with a one-hour backstop that matches the page's existing revalidation window. The template lookup becomes asynchronous. The dev and build lifecycle hooks that generated the file are removed, as is the ignore rule for the generated file.

Design decisions are fixed in #132 and should not be relitigated: the caching primitive is the "use cache" directive behind its narrowly-scoped config flag — not app-wide cache components, and not the legacy unstable cache helper.

⚠️ The cached unit must be the finished snapshot, not the underlying HTTP call. The GraphQL client issues POST requests, and Next.js never caches POST fetches. Caching at the wrong level silently re-queries WordPress on every regeneration — roughly a second each time — instead of once per invalidation.

Acceptance criteria

  • A page renders its FSE template correctly with the previously generated snapshot file deleted from the working tree
  • A production build succeeds with WordPress unreachable, and no longer contacts WordPress at all
  • Polylang-translated template parts still resolve per language, falling back to the default language when a translation is missing
  • Navigation inner blocks are still fetched at request time rather than served from the snapshot
  • Exactly one pair of GraphQL queries occurs per cache fill, not one per page regeneration — verified by logging or network capture
  • Snapshot retrieval degrades to an empty-templates result when WordPress errors, rather than throwing and taking pages down

Blocked by

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestready-for-agentTicket is scoped and ready for an agent session to pick up

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions