I have this super abstract, high level Graph API shit going on in my head. It is not GraphQL. I feel like GraphQL is not really very graphy, but is more like just exposing a VERY BIG relational DB over the network. In something very graphy, the edges are more important than the nodes. The documentation would have to focus there and nodes are not "user" and don't really even have... types? I find it hard to discuss because it's almost the inverse of how most people think about systems.
But if you do it the way in my head, you get a LOT of nice benefits out of it. One is that it would be extremely flexible. It reduces your change-over-time costs to levels I hadn't really believed possible when thinking mostly of HATEOS and REST and friends. All the API design tricks from Hypermedia that help you delay and avoid versioning your API are pale shadows of stuff that is sort of structurally built into this idea in my head.
And also I'm not sure what's needed in the schema. If following the `Author` edge from a certain node gets you to a node that should have edges `Name` and `Image`, should the schema express whether those nodes (and thus, names and images) might collide between a post author and a comment author. Like... one human might write both a post and a comment and updating the blog->post->author->name node will also cause a change in some blog->post->comment->author->name node...
ｃｙｂｒｅｓｐａｃｅ: the social hub of the information superhighway
jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal