The Baked Data architectural pattern
Next.js (and probably its competitors) does this same thing (<a href="https:&#x2F;&#x2F;nextjs.org&#x2F;docs&#x2F;basic-features&#x2F;data-fetching#getstaticprops-static-generation" rel="nofollow">https:&#x2F;&#x2F;nextjs.org&#x2F;docs&#x2F;basic-features&#x2F;data-fetching#getstat...</a>), just much more elegantly and modularly, allowing you to work with any headless CMS while still maintaining the benefits of a static, &quot;baked&quot; dataset that gets deployed alongside static code. It just caches API responses at build time into local JSON.<p>The thing is, no matter how you bake the data, it has to be edited somewhere. That &quot;somewhere&quot; is rarely good as Markdown files or or SQLite for all but the most trivial implementations. In real-world mid-sized websites, content editors want something easier to work with. Having an actual CMS, even if it&#x27;s just a decapitated Wordpress, makes their lives much easier. And you can still get the benefits of baked data.<p>With incremental static regeneration (<a href="https:&#x2F;&#x2F;www.smashingmagazine.com&#x2F;2021&#x2F;04&#x2F;incremental-static-regeneration-nextjs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.smashingmagazine.com&#x2F;2021&#x2F;04&#x2F;incremental-static-...</a>), you also get the benefit of post-build on the fly revalidation and &quot;rebaking&quot; without requiring a full rebuild, courtesy of a server that checks for data updates in the background and rebuilds only the affected pages.