1. CMS experience for non-technical teams: marketing, product, content, etc. 2. Graphql api to avoid lock-in. Tomorrow you can take your data to AWS Appsync, etc 3. Ownership of the data: Contentful, Prismic, etc are great - but Strapi allows you to own the data. Even in its simplest form, its a sqlite file you can check in to git.
Do non technical teams know or care about Graphql Api ? As someone who works for non-technical teams-- they only care about getting their job work done with the least amount of friction. These teams end up on Wordpress for the simple reason that they can to to themeforest, pick a theme and say this is what they want their site to look like.
If you can convince the tech team to build your entire infrastructure on Wordpress/php...then great, go for it. But most likely the rest of your app is built in different languages.
So a "headless CMS" like Strapi gives a brilliant CMS experience and exposes the content as a graphql api. To be fair, you can achieve that in Wordpress as well - https://www.wpgraphql.com/. But I suspect that most engineering will be happier to touch a reactjs based product versus a PHP based.
Yes, you can. But it feels, acts and works exactly like the thing it is: a hack held together with ducttape and prayers.
This is not a diss to WordPress or to the wpgraphql community: they do great work. But comes from experience at running a WP hosting company (and solving all sorts of WP issues). WP was designed as a blogging tool. This shows, because everything you make it do that is not blogging is clumsy and hackish at best, and very insecure/unstable/buggy at worst. The further you go from "a blog" the worst this gets.
Turning WP into a headless API-backend is such a thing: WP was never designed for this and it shows.
I'm surprised to hear someone who has run a WP hosting company say that using WP for anything other than a blog is "clumsy and hackish at best". I've also run a WP hosting company and would suggest otherwise
Here's what WP is particularly bad at:
* Anything "user generated" where "users" are not part of a trusted group of editors. Even the feature "comments" that has been in WP since the very start breaks down very quickly and is extremely tough to manage, tune, or moderate.
* Anything that is highly dynamical, such as popularity counters, voting, threads (see above) or any other UGC (see above) breaks immediately with any kind of load b/c all performance optimisation in WP evolves around caching. Which is a good strategy for a publishing platform.
* Anything that has workflows or requires state for visitors. e-commerce, payments, sign-in, etc. Hampered by the limited abilities to tune performance (see above) but mostly hampered because WP has no framework or tooling built in to manage "state", build "state machines" and so on. Other than "just cram it in cookies", but that is no state-management. I've seen WP cookies nearing 0.1MB being passed over the line for every request "the site is getting slow, I hear", said the client. Well.... sure!
* Anything that requires async processing. Tucking wp-cli into a cron-job works but is clumsy and fragile. Spawning workers, jobs, events or anything else is lacking in tooling. You probably don't need this, but when you do, WP is your enemy.
So, sure, WP is really neat when you have a known, or dedicated team of publishers and authors that write stuff, which is then read by visitors. For this model (which I call "the blog") it is very well attuned, especially if you keep it at those generics. Especially when such teams work on many different such "editorial sites" at once: the familiarity of WP then helps a lot.
But in most other cases there are either far better suited publishing platforms attuned for your exact needs and niche. Or there are frameworks that let you build such an attuned system far easier than through "WordPress Development".
Sounds to me like you already made a good case for why those products exist.
Sure, you could also call HTML structured content, but using HTML for expressing the semantics of the content instead of the presentation has always been a bit of a pain. Plus you wouldn't really want to use HTML as a format to share this kind of data with for example mobile applications.
You could use XML, but I'd say that's basically the same as JSON with a fixed schema but with more angle brackets, which is pretty much what those headless CMSs return.
Then on top you need the devs to build the server, and to maintain the DB, to add a querying API, to add SDKs and tooling that enable smooth integrations with the new API, the workflows on top of the pure content, a UI that is intuitive to the people maintaining the content, security audits, scalability for when more parts of the company want to use your tooling etc etc.
Following your reasoning you could also say "Payment provider" is a marketing term for something that is just a DB that needs to sync with some banking APIs and AWS is just APIs in front of some DBs and VMs and analytics solutions are just a JS SDK on top of some DB.
Fundamentally everything we build is just some kind of frontend or abstraction on top of a DB. I don't see how that makes it in any way pointless.
so you can move from AWS AppSync to Strapi to Graphcms without changing your code. As long as an infrastructure implements the Graphql api standard, your code will work without changes.