Planned module: @dataplan/graphql about crystal HOT 4 OPEN

Awesome @benjie, thanks for the detailed response! Excited to dive in an explore this more

PS funny enough, my exploration of grafast was actually on a plane back from a conference

from crystal.

Hi @brandonwestcott; creating a @dataplan/graphql for this exact purpose is on my long term plan! Would be great for you to start this early.

You should use step classes to track which attributes are accessed. You'll end up with a lot of steps during planning, this is expected - as one of the final steps they can be optimized away. You might want to look at the broad idea (not the specifics, they're way way way too complicated for this use case!) of how the Postgres integration works; broadly:

• PgSelectStep represents a select ... from ... operation
• PgSelectSingleStep represents a single row from the result
• PgClassExpressionStep represents an expression on a single row, for example access to a particular column, or a Postgres function call or similar

Critically all these exist before optimization, but when optimization happens many of them are inlined into their parents/etc and it all collapses down to a much simpler plan.

You might want to look at how the loadOne() step works too, since that tracks access to .get(field) so it knows which fields to request. .get(key) is becoming a convention, and will probably be more explicitly a protected pattern in a future version (e.g. "everything that has a "get" method must obey X, Y and Z").

There are some subtleties to GraphQL in this regard; for example in Postgres every PgSelectStep can be an SQL statement on its own, or can be inlined into a parent SQL statement, but that's not true in GraphQL - only root level fields can be queried on the root, all others maintain their heirarchy.

Further, when polymorphism comes into it you may need to query additional attributes that won't actually be returned in the result. This probably isn't an issue, but does mean that you might need to do careful management of aliases in outgoing queries to prevent users shaping incoming queries maliciously causing you issues (e.g. fragment Foo on User { __typename: username } might trick your system if you're not careful!).

I think you would want:

• A step class representing a GraphQL operation
• A step class representing a GraphQL field
• A step class representing a GraphQL inline fragment
• A step class representing a GraphQL named fragment

Deduplication of each of these should follow effectively the field collection rules in the GraphQL spec (if a field is specified twice with two different sets of arguments (and the same response key) then that would be forbidden by the GraphQL spec's validation, but what we'd do would be to just assign two different aliases to it when we request it from the remote server).

Try and think very locally in steps, e.g. each layer is just representing a single selection on the parent selection set, or similar. Then your big complex system can be composed of all these small isolated features that are easy (ish) to reason about.

I hope this helps! I'd love to track your progress on this.

from crystal.

Ooo, I thought this rung a bell! Turns out that I started work on this back September last year, on the plane over to GraphQLConf! You can actually see my timezone change in the commit timestamps :D

The code in this branch is super out of date, a lot of the patterns have changed now, but perhaps it'll give some inspiration? Also looks like I stopped halfway through some refactoring or something, so I've just added that just now... no idea if it's coherent.

https://github.com/graphile/crystal/tree/dataplan-graphql

from crystal.

Keeping this open to track @dataplan/graphql. Let me know if you need any input on it (you may get faster responses on Discord; make sure you give yourself the Dev role).

from crystal.