On Preview as a Service…

Minor rant: I’d like to see CMSs start providing “rendering as a service.”

What I mean is that your CMS should have an endpoint that can accept a JSON representation of content, and render a preview, even if it doesn’t actually “own” that content. The endpoint should be stateless and transactional. Even… hypothetical?

Hey CMS. Hypothetically speaking, if you did have content that looked like this, and that lived in X location in your repository, how would you render that?

This would make decoupled preview so much easier, and allow cleaner integration of upstream tooling. Optimizely CMP, for instance, does “preview by survey” – when you “Request Preview,” it calls out to however many downstream systems you like and gets previews from them.

However, the average CMS doesn’t want to provide a preview for something it doesn’t own. It will usually only preview something that lives in its immediate repository in a “draft” state of some kind.

Why is this? I’ve done projects where we’ve implemented a “Rendering Service” that we throw data at to have it rendered. The service didn’t operate off data in the repository, it operated off whatever data you threw at it, returned a rendering of it, and then it immediately forgot about it. It was up to you to persist or deliver the provided rendering however you wanted to.

Example use case: “I wrote this blog post in separate tool. I haven’t put it in the CMS, but I will eventually. So, O Mighty CMS, pretend you own it for a second and show me how you would render it. Then just forget I asked about it.”

This is so, so handy. Systems should implement rendering this way – it would make life better for everyone.