Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Comments on InputUnion RFC #817

Merged
merged 5 commits into from
Sep 2, 2021
Merged

Comments on InputUnion RFC #817

merged 5 commits into from
Sep 2, 2021

Commits on Jan 28, 2021

  1. Comments on the proposal 

    Hi, thanks for this extensive and in-depth work.

I will try to keep my comments concise (which might make them sound agressive, apologies if that's the case, it's definitely not the intent)

This PR touches one of the most challengeable founding philosophical choices of GraphQL: having 2 different type systems for input and output.

I understand that the sender -> receiver relation is an unbalanced one: the sender has obligations, the receiver has options.

However:
 - ALL GraphQL users use programming languages (Javascript, Java, C#, Python...) which make no difference between input and output types
 - I actually don't know any other protocol that does that (is there one?)
 - having 2 different type systems for input and output solves (does it?) an implementer problem, not a user problem

The lack of polymorphism on input is only a side-effect of the aformentioned original choice.
In an unreal world, rather than tweak GraphQL to fix that, it would be time for GraphQL2, unifying input and output types (amongst other improvements).

That's very unlikely to happen, but saying so helps forming an opinion on the various proposals:
 - adding yet another polymorphic construct only available on input 'smells' like increasing confusion 
 - it would increase the gap between input and output type systems, rather than reduce it

From there, I think proposal graphql#5 @OneOf is the most useful one:
 - it acts as a constraint on existing type constructs rather than yet another type construct
 - it expresses the required behavior much better than proposal graphql#7
    @ericvergnaud
    ericvergnaud authored Jan 28, 2021
    Configuration menu
    Copy the full SHA
    ae21de3 View commit details
    Browse the repository at this point in the history

  2. Comments on the proposal 

    Hi, thanks for this extensive and in-depth work.

I will try to keep my comments concise (which might make them sound agressive, apologies if that's the case, it's definitely not the intent)

This PR touches one of the most challengeable founding philosophical choices of GraphQL: having 2 different type systems for input and output.

I understand that the sender -> receiver relation is an unbalanced one: the sender has obligations, the receiver has options.

However:
 - ALL GraphQL users use programming languages (Javascript, Java, C#, Python...) which make no difference between input and output types
 - I actually don't know any other protocol that does that (is there one?)
 - having 2 different type systems for input and output solves (does it?) an implementer problem, not a user problem

The lack of polymorphism on input is only a side-effect of the aformentioned original choice.
In an unreal world, rather than tweak GraphQL to fix that, it would be time for GraphQL2, unifying input and output types (amongst other improvements).

That's very unlikely to happen, but saying so helps forming an opinion on the various proposals:
 - adding yet another polymorphic construct only available on input 'smells' like increasing confusion 
 - it would increase the gap between input and output type systems, rather than reduce it

From there, I think proposal graphql#5 @OneOf is the most useful one:
 - it acts as a constraint on existing type constructs rather than yet another type construct
 - it expresses the required behavior much better than proposal graphql#7
    @ericvergnaud
    ericvergnaud authored Jan 28, 2021
    Configuration menu
    Copy the full SHA
    7494b5f View commit details
    Browse the repository at this point in the history

  3. Update InputUnion.md

    @ericvergnaud
    ericvergnaud authored Jan 28, 2021
    Configuration menu
    Copy the full SHA
    7b68738 View commit details
    Browse the repository at this point in the history

  4. enrich the discussion to highlight the need to avoid the introduction… 

    … of new type constructs
    @ericvergnaud
    ericvergnaud committed Jan 28, 2021
    Configuration menu
    Copy the full SHA
    7e54c97 View commit details
    Browse the repository at this point in the history

  5. clean up merge dirt

    @ericvergnaud
    ericvergnaud committed Jan 28, 2021
    Configuration menu
    Copy the full SHA
    264b93d View commit details
    Browse the repository at this point in the history