Providing rules/explanations/algorithms for satisfiability

[Aenimus]

In today's session, I attempted to succinctly describe satisfiability thus:

If a path from a type to a leaf is ever possible (defined), that path should possible from all instances of that type.

This seemed to cause some confusion/disagreement. Perhaps it was a poor choice of words.

What I meant by this is that the composed graph produces a contract that defines what can be requested (selected) on any type. These selections must be possible at all times, i.e., no matter where that type is yielded (whichever graph, whichever layer of nesting).

An "entry point" for a request is through a root field node. That root field either outputs a leaf node type or a composite node type. In the event of a composite node type, all fields that are defined on that type in the composed graph must be resolvable, i.e., it must be possible for the client to select them and then for the router to return data. This is recursive (composite fields can define composite fields, etc.).

CC: @martijnwalraven @kamilkisiela

[kamilkisiela]

Yes, I thought you meant something different.

In my head, if we turn fields as Edges and types as Nodes and include there abstract types as well as entity types (lookups) - and of course their conditions (key fields, required fields etc), we end up with a graph.
All Nodes would be assigned to a subgraph.
When it comes to @provides, it's just a graph "attached" to the original (big) graph that has no conditions (requires no additional checking).

We would also need to represent the public schema (the one that user is able to consume and query).

This way we traverse the "public" graph and when doing the transitions, we check if the "move" is possible to perform in the "private" graph.

It's super slow and won't work for schemas with a lot of lookups and abstract types, but should give us a good base to described the algorithm. It could be BFS or DFS, does not matter really as both are equally simple.

[PascalSenn]

Maybe we can start with writing down some cases that show impossible states. If we want to find a good abstraction to describe the algorithm, we first have to know exactly what we want to validate

[PascalSenn]

algorithmically we can also do multiple passes through the graph. If it's easier to describe what we validate for, we can have different rules for provides, requires, lookups etc.