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.

I have one enormous hurdle, though: It's so abstract, I have NO IDEA how to even begin expressing the most trivial of graph schemas. Like... a blog that has posts, comments and authors. I get turned around in part because there's not really nouns in my thing? It's all just the relationships. So it's hard to think about posts without thinking... about... posts?

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...

Fuck. This is impossible to talk about.

And I tried using a diagram tool to express things, but it got even WORSE in some senses. Ugh.

OTOH, I came up with a rad name for this thing I'll never write any code about: Precipice. It's all about edges, see... and it's dangerous to fall off it.


wouldn't it be actions, essentially? cataloguing state of being/ownership/etc. verbs and expressing the acted upon things differently, versus cataloguing nouns and having the relationships expressed in other forms

actually in a way that is a description of what accounting does -- things are categorized by what action they resulted from or caused, because all the amounts are either money or multipliers for money.

(maybe I'm misunderstanding; it happens a lot, truly)

@sydneyfalk That sounds like event logging. Which is more about how you're storing it than how you access or navigate it, yeah? I think you could do both things or one without the other. Depends on the manner of change your data experiences, I guess.

@ontploffing @benhamill Keen to see any design docs or mock up of this idea, even if it's just "thinking out loud" kinda stuff.

@ontploffing In that its a schema, at least, but it's almost… inverse of the model.

Sign in to participate in the conversation

cybrespace: 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