Benefits of a build-phase headless CMS

May 12, 2020—4 min read

A build-phase headless CMS reduces the burden associated with infrastructure matches that of a global CDN (which serves your static assets). There is less infrastructure cost associated with it, lowers the dev-ops burden, it essentially becomes more serverless friendly, and it helps to further improve User X, Developer X, Customer X, and Content Creator X.

The traditional monolithic CMS relies on a tight coupling between the front-end and the back-end, everything is tied up together and the platform is responsible for serving, displaying, and updating the content, there are several limitations and inefficiencies with this approach and hence it’s quickly losing popularity for good reasons.

Static Site Generators are amazing tools for building modern websites. They make it much easier to create and compile modern apps and websites, and allow for easy integration to pull content via an API on when deploying or re-deploying.

The Headless CMS problem

The Headless CMS approach has risen in popularity, allowing it to serve as a central hub for content distribution on multiple channels. Additionally, the front-end team gets the flexibility to ship faster and better experiences to an end-user, but it also means an extra layer of infrastructure that needs to be fast, scalable and secure, technologies like autoscaling, Redis caching, GraphQL certainly make it possible to deliver content fast, but for many uses cases, a build-phase headless CMS might be a better approach.

A headless CMS works in a JIT (Just in time) flow, meaning that content is accessed on-demand via a RESTful API or a GraphQL. This means that if you want your website or app to be fast, performant, and reliable, you have a dependence on that your CMS Infrastructure.

Accessing content at build time

A core tenet of Jamstack has been to pre-render (pre-compute) as much as possible, which has given prominence to static site generation. The key idea is that computation that would have happened later on, in the request’s timeline, has now been shifted to the build phase, performed once and made available for all users to share.

Static Hoisting by Guillermo Rauch, Vercel.com CEO

Next.js released a new version that makes it super easy to generate a static site via its Next-gen Static Site Generation (SSG) Support for websites or web applications. Its parent company Vercel already supports incremental builds and is working towards improving the approach, allowing to integrate more content without affecting build time.

Reduce the point of failure

A CMS that is available at build time, only exists for the purpose of managing the content (as it should have always been) by its stakeholders, as it’s accessed on build time (via an API) to generate static assets the system responsibility is completely isolated from end-users.

If the CMS is only required on the build-phase, it means that now the only responsibility it has is to provide a great experience for interface for the of the CMS is to provide a

References

Author avatar