so the choice of wordpress or nodejs or whatever is a developer driven decision. However, the non-technical team will want a brilliant CMS experience.
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.
> To be fair, you can achieve that in Wordpress as well
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.
While I agree some of these plugins do start to feel hacky, WordPress Core has evolved quite a bit from being just a blog. Custom post types are not even new, but come to mind.
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
When I say "anything other than a blog", I do mean "blog" in a broad sense. A "publishing platform" may be a better term but is rather vague.
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".
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.