Due to how there’s one new ‘great’ headless CMS product coming out everyday, it’s best to never write your code in a way that couples the CMS’s data fetching and querying mechanism to your code.

I’m not sure of how this would be implemented yet but I’ll do this for any other project I work on.

The goal and benefit here is to easily be able to switch to another CMS if one goes defunct.

Off the top of my head, any CMS that requires too much coupling should be avoided if there’s no way around that coupling.

And even if that CMS offers live preview functionality like Sanity, it should always be implemented in a way that’s decoupled from the rest of the website so that if one moves to another CMS that doesn’t have this feature, you don’t have to change any code (at worst, just cleanup the excess code powering the feature).

Another good thing to consider here that’d weigh on this is your content model. Your content model MUST be independent of your CMS. If your content model requires a particular CMS to work, you should fix that by remodelling (except you have a very good reason not to do so!).

Simple test:

If X CMS went out of business today or if I wanted to switch to another headless CMS, how easy would it be change my code to do this.

Self-hosted CMSs are a great solution here too, but self-hosting isn’t always cheap, especially for non-dollar clients.

Super-excited to play with this in a future project!