Perhaps your CMS serves multiple front ends: a website, or a mobile app.
> Why would I want a CMS based on GraphQL?
The way I see it, the CMS is not based on GraphQL, it's just a CMS that you can query with GraphQL. I haven't used GraphQL at all, but it seems like it could be useful for working within a system where you need to bring data from many different REST endpoints together. Usually I would have to hand code something like this myself on the backend, but with GraphQL it seems like once you have it all set up, you can get data from multiple APIs, while specifying the schema of your response on the client instead of on the backend.
> What is wrong, with plain old HTML?
Nothing, if you can build what you want to build with "plain HTML" then do it.
It's describing the CMS, not the API. It's not so familiar to software engineer types, but is pretty well understood in publishing / Drupal / WordPress space.
So you're supposed to put test/markdown and images in it and basic structure like title/date/author? What about data oriented systems instead of content oriented?
I'm not sure I understand your questions. I haven't used GraphCMS so I don't know if they let you store HTML, but some CMS do, and yes that makes it harder to reuse your content in a context other than the web. I don't know, but I assume that you could probably make GraphCMS store HTML if you wanted to. The question of "can the CMS store HTML" seems orthogonal to the question of "Is it headless?" or "Does it have a GraphQL or REST API?"
Nothing is wrong with plain old HTML. Going headless gives you frontend freedom. It means integrating your content on any platform you like: web, mobile, smartwatch, fridges and toasters (if they are smart enough). It's interesting that we mostly see people using a headless CMS just for web.
Why?
Because they can pick the frontend stack they like! React, react-static, Gatsby, vue, nextJS etc.
You can pick the stack you like most. It is much easier to find a react developer than someone who knows how to write good drupal templates.
Why GraphQL? Because it's awesome! I can highly encourage you to just try out a GraphQL API and see yourself. It is designed for fetching related data efficiently and it will give you a huge boost in development productivity, which means lower development costs and faster time to market.
A Headless CMS means you define all of the frontend interpretation of the content. Basically a GUI for your database.
If you have lots of queries happening behind the scenes whenever someone makes a request that seems basic- like how Facebook gets a list of comments on a post, plus the friends who made them, and a list of different reactions to each comment, and other stuff that rapidly creates a complex graph- then GraphQL simplifies. The REST way involves all of those extra calls, GraphQL gets everything in one request.
Not specific to GraphQL, but plain old HTML doesn't work when other non-technical people are managing the content of the site. They need a GUI, and hence the need for CMS's in general.
Perhaps your CMS serves multiple front ends: a website, or a mobile app.
> Why would I want a CMS based on GraphQL?
The way I see it, the CMS is not based on GraphQL, it's just a CMS that you can query with GraphQL. I haven't used GraphQL at all, but it seems like it could be useful for working within a system where you need to bring data from many different REST endpoints together. Usually I would have to hand code something like this myself on the backend, but with GraphQL it seems like once you have it all set up, you can get data from multiple APIs, while specifying the schema of your response on the client instead of on the backend.
> What is wrong, with plain old HTML?
Nothing, if you can build what you want to build with "plain HTML" then do it.