graphql / graphql/graphql-spec

Why are edges and their properties second class citizens?

Open
#910 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
14.6k
Forks
1.2k
PR merge metrics
No merged PRs in 30d

Description

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:
![image](https://user-images.githubusercontent.com/29461076/146673042-231c4073-f522-4b85-9e20-1c6429c14985.png)

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?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.