Why are edges and their properties second class citizens?

[lveillard]

It's really hard to work with edges, their directions and their properties in Graphql. We are basically forced to create nodes that interconnect nodes. Let's for example take in consideration this schema:

In order to make things easier, "Applied to" edge must be converted into a node, but it should not be like that.

F.i: Candidate it's defined by one id (email, name, ID card number...)
However, application is defined as the relation of 1 candidate with 1 job offer. Is not possible to have one and not the other. Is clearly an edge.

Things get a bit more complicated when we realize the edge "Applied to" has also an edge connected to it: Interviews. I have no idea how to cope with that (edges having edges) in the theoretical domain, but my main point is about how we name things in graphql. I feel something is missing.

Candidate is clearly a node, Job position and recruiter are clearly nodes also. Interview is arguable as you definitively need at least one candidate and one recruiter to define it, but I'm not as annoyed defining it as a node as I am doing so with "Applied to"

Would love to get your view on that but specially, even if it is maybe not the best example, i would love to understand what is the long-term roadmap regarding edges and their properties: Are we planing to make them first class citizens or will be always graphql a standard node-focused?

[lveillard]

To illustrate a less weird schema (without edges connected to edges) let's take this schema from tigerDB documentation:

Some data belongs to the edges, for example "attend" is clearly defined by two ids: Person and School, so it's not a node, but an edge. And then you can have some information there like "first day, average score...."

Some graph DBs like dgraph had even to create their own querying language (like DQL) in order to manage fields on edges (what dgraph calls "facets") . Of course it is impossible to translate DQL queries/mutations managing facets to graphql, one can play with those only using DQL.

To sum all this up: I feel like graphql standard is really limited when working with these. And FMHO properties at edge level are one of the key ideas behind graph theory, that make them more close to reality than schemas architectures forced by SQL or document DBs

[acao]

The relay spec is a graphql superset that introduces edges, nodes & connections. This is the most popular graphql superset but there are others.