Processwire as a Headless CMS

[clsource]

Hello,

Upon reading these articles

https://dev.to/maxlaboisson/an-introduction-to-api-first-cms-with-directus-open-source-headless-cms-9f6

https://snipcart.com/blog/jamstack-clients-static-site-cms

I was thinking that PW can be used for a Jamstack or Headless CMS with no changes at all.

You can easily create  REST Api with PW or use the GraphQL module

https://github.com/dadish/ProcessGraphQL

 

So ProcessWire is an Open Source Headless CMS since 2010

[adrian]

Maybe I don't fully understand the term headless, but I would have thought that PW is ALWAYS headless, even with our typical way of using the API.

Surely headless doesn't just mean delivery via JSON etc, but rather simply no forced output. I have used PW in the "regular" way for websites, but also as a JSON source for SPA web apps and mobile apps. In my mind, these are all headless, but maybe I I still don't get it, or maybe that is actually what you are saying anyway

[teppo]

5 hours ago, adrian said:

Maybe I don't fully understand the term headless, but I would have thought that PW is ALWAYS headless, even with our typical way of using the API.

I'd say that technically ProcessWire probably isn't a headless CMS – but it can of course be used as one, and quite effectively for that matter 

ProcessWire is very much a border case, but my impression is that if you can build a front-end with(in) a CMS, it's no longer strictly speaking a headless CMS. And you can build a front-end with ProcessWire. Sure, you interact with an API, but it's a "local" or "in-app" API, not (only) an external one.

Hope that makes sense. And, mind you, I'm not saying that ProcessWire is worse than a "real" headless CMS – in fact I'd argue that it's a better choice for many use cases, but that's obviously up to debate 

[kixe]

ProcessWire is even more, it has capabilities to be a

• conventional CMS with highly configurable Administration Interfaces, Templatesystem, Database Mangement/ Access and render tools for the output of dynamic markup
• headless CMS providing content data via API (JSON, GraphQL) and optionally static HTML + JavaScript (HUGO/ Jekyll)
• WAF (Web Application Framework) a platform to build a headless CMS or other App/ SaaS on top of fit

Make your choice!

 

[kixe]

... and don't forget to read this

 

[teppo]

This sounds familiar: https://www.magnolia-cms.com/blogs/christopher-zimmermann/detail~&hybrid-headless-cms~.html.

[dragan]

sigh... I must say some folks are quite good at marketing. I don't blame them. It's a free market. There's nothing I saw in this article that wouldn't be possible with PW (and without any extra modules either), more or less out of the box. What Magnolia calls fragments is apparently nothing more than PW's fields. But I have to hand it to them, they seem to know how to translate all that tech lingo to marketing speak.

 

[dragan]

OMG, not again... https://www.pilcro.com/blog/headless-cms

Quote

So what is it? Headless CMS is a Content Management System without a front-end. There is no theme to choose, no pages or UI to build your web pages. Its Wordpress but you provide the webpage.

There is no presentation layer.

You create the content, but you don’t specify where it is presented. The content itself is only available as raw content that can be requested by apps via a programmatic API.

By that definition, PW is most definitely a HCMS...

[dragan]

and again... this time, an HCMS powers a pizza book ?

https://medium.com/buro-int/headless-cms-for-a-printed-pizza-book-54b39827e651

 

[pwFoo]

I thought about different cms/f and headless cms (for example directus, cockpit). 

Processwire can be used as headless cms out of the box (response with json) or with a rest api module.  Directus / cockpit looks great, but it would be so much easier to use processwire with custom code / modules to add some server side features I think?

Will PW as headless cms bloated by template system and some more non-headless features? Maybe best would be a rest api module with a process module? Would that skip some not needed core parts like template parser? Will that reduce overhead or maybe there isn't really overhead by not needed core features?

[psy]

I know that headless cms has been a hot topic for a while. I've experimented with several frontend frameworks (Angular, React, Vue, etc) and I just don't get it. Maybe for huge corporations with multiple dev teams and big budgets, OK. For 95+% of use cases however, I find headless cms/js frontend to be a major pain with no discernible benefits. From a frontend web UX, they're often slower than a well built PW site with caching (eg ProCache).

For native apps, something like api calls to/from PW/Dart via json would do the job.

Am I missing something other than a desire for JS devs to earn extra $$$?

[LostKobrakai]

Personally I'd only do headless cms's with static sites. Where the static site generator pulls from the external cms for building its content. This is great because the cms is only concerned with providing data and the static site generator is concerned with rendering those into html. 

[Craig]

I've used PW in mostly headless mode for a recent project at work.

A new client needed to add a map of case studies to an existing bespoke site that was built by another party, and an easy way to manage them.

I set up a new PW site to manage the case studies, added a basic JSON API as the only bit of front-end, and made a simple Vue app (to be embedded on the client's site) to fetch the data, filter items, and render the map/markers and detail view.

Didn't take all that long to build, and the client is happy with the functionality. Each case study is associated with other bits of information, like contacts, keywords, sectors, location - and PW really made this easy.