RFC: Fragment Arguments (parameterized fragments) for GraphQL #865

mjmahone · 2021-05-05T21:41:45Z

This is a proposal to bring Relay-style Fragment Arguments into the Spec as an optional, client-only language feature.

Overview

We would allow clients to write GraphQL like:

query Q1 {
  ...Number(x: 100)
}

query Q2($i: Int = 3) {
  ...Number(x: $i)
}

fragment Number($x: Int!) on Query {
  number(value: $x)
}

which would, prior to sending to the server, be transformed into two unique queries that current spec-compliant servers would understand, such that it behaved like the queries were written like:

query Q1 {
  ...Number
}

fragment Number on Query {
  number(value: 100)
}

and

query Q2($i: Int = 3) {
  ...Number
}

fragment Number on Query {
  number(value: $i)
}

The exact mechanics of how the query gets rewritten could be different per client, but the behavior should be identical. This RFC seeks to describe the new syntax, as well as adding additional validation for clients that choose to support fragment arguments.

Background

Relay has seen a lot of usage of their non-spec-compliant @arguments and @argumentDefinitions directives, but they're both cumbersome to use and fail basic Spec validation (directives with arguments used but never defined). They accomplish this by pre-compiling any GraphQL definitions using @arguments and @argumentDefinitions to transform the document such that, by the time it's sent to the server, it is spec compliant. However, Relay's user-facing directives both do not conform to the spec and also provide a pretty cumbersome, somewhat unintuitive user-facing design.

This proposal is to allow clients that pre-compile their GraphQL prior to sending it to the server (such as Relay) to have a built-in syntax for passing argument values into fragment spreads for fragments with well-defined argument definitions.

Champion: @mjmahone

andimarek · 2021-05-05T22:28:35Z

@mjmahone some general questions:

This would split GraphQL syntax between client and server. Is that correct?
Why not make it a full feature which are implemented by the server?
What is the practical reason to bring this into the spec: change of client side validation rule?

thanks

mjmahone · 2021-05-06T14:36:06Z

This would split GraphQL syntax between client and server. Is that correct?

Yes, but that's already true for clients like Relay today. This spec proposal would have the actual spec basically accepting that current reality.

Why not make it a full feature which are implemented by the server?

I would like to, but there's a lot higher of a bar to this. Especially in terms of backwards compatibility: this spec RFC provides a way for a client hitting any current-spec-compliant server implementation to use these new idioms, without waiting for a server upgrade.

Basically, I anticipate more changes in this space, including changes to server execution behavior, but I'd be loathe to block a client from using the new paradigm until after we have the server-side figured out.

Importantly: this paradigm is widely used within FB inside Relay, but the ergonomics of @arguments/@argumentDefinitions is a major complaint. We currently face the chicken and egg problem, though: Prettier and GraphiQL are incredibly important tools for us, and we can't use the better syntax for Relay internally until Prettier and GraphiQL support it, but those repos don't have a path right now to supporting non-graphql-js-supported syntax, and graphql-js explicitly only supports spec syntax (or spec-RFCs under feature flags).

What is the practical reason to bring this into the spec: change of client side validation rule?

In short, tooling. GraphiQL and Prettier's GraphQL plugin both rely on the spec's interpretation of "what GraphQL is". In some sense, that eliminates our ability to iterate on "future GraphQL": if we need both the server and client to agree on any new "spec features", even when the client could "transpile" to previous-spec-GraphQL (as people call the process of JS-new to JS-old compilation), we end up in a chicken-and-egg situation for introducing new paradigms. New paradigms, without tooling support, can't get adopted.

An alternative to introducing this in the spec would be to introduce it purely in the tooling repos: this is certainly possible, but if graphql-js is meant to exactly match the spec + spec RFCs (with feature flags), that precludes tooling from relying on graphql-js: in this world, either people can't use GraphiQL and Prettier with the new syntax, or GraphiQL needs a custom AST that it locally compiles to graphql-js's AST (and will need to constantly update the custom AST with any new graphql-js features), and Prettier will have to rely completely on a custom AST that needs to stay in sync with graphql-js.

It seems better IMO to put an "optional extension" into the spec "if we allowed fragment arguments, this is the syntax we'd use. For clients using the new syntax to stay compatible with the current server spec, here's the limitations we need to add via extra validation rules".

IvanGoncharov · 2021-05-13T14:36:03Z

@mjmahone In the long run, we need to switch graphql-js to have an execution plan stage before executing the request (since it what the majority of other production-ready implementations already did).
And having an execution plan with all arguments coerced and prepared for every field means performance and code complexity of this feature would fully handle during the creation of the execution plan.

My proposal is to merge it as RFC and implement parsing and validation in graphql-js but create a separate validation rule (enabled by default) that forbids argument definitions on fragments.
That way GraphiQL and another tooling can just disable this single rule until we implement this feature on the backend.

mjmahone · 2021-06-02T01:06:22Z

I actually think the executor implementation is not that difficult: graphql/graphql-js#3152. I'll iterate on the spec changes required once we have some form of consensus that this experimental implementation is OK to iterate with.

rfcs/FragmentArguments.md

ivome · 2021-06-09T15:15:58Z

I think it would be awesome if we could add this without the rule "Fragment Argument Uniqueness". I don't see a logical reason from a spec point of view why this rule needs to exist. It might be more complex to implement on the server or client, but not having this rule in place would have huge benefits IMO:

With the rule in place, a user of a fragment has to have knowledge of the entire query tree to know if the fragment can be used in a certain context. Without the rule, all dependencies can be explicitly defined throughout the entire query tree, and a component that uses a fragment can be used any number of times with any variables in any context.

As an idea, we could add a rule that all the variables that are used within a fragment have to be defined on the fragment definition.

Valid example

query Query($large: Int!, $small: Int!) {
  user {
    ...ProfileImage(size: $large)
     friends {
       ...ProfileImage(size: $small)
     }
  }
}

fragment ProfileImage($size: Int!) on User {
  imageUrl(size: $size)
}

Invalid example
This would be invalid because the used variable is not defined in the fragment definition:

fragment ProfileImage on User {
  imageUrl(size: $size)
}

Benefits of this approach:

Fragments that use variables become modular and composable. We eliminate the dependency between fragment and query definitions which has to match right now. This would make it easier to scale complex queries.
We eliminate errors that arise when a user accidentally creates a fragment variable with a name that is already used in another part of a query with a different type for example.
No knowledge required anymore by fragment users and implementors since all dependencies are explicitly defined right where they are used.
We can validate individual fragments without having to know the query in which they will be used.
Allows us to implement better autocomplete features in developer tools.

To ensure backward compatibility, we can detect if there are variables passed to fragments in the query definition. If there are fragment variables passed, the query is executed with the new strict logic, otherwise, the current validation rules apply.

mjmahone · 2021-06-10T01:53:58Z

@ivome: I agree that making fragments truly modular and composable is desirable. There's a lot that can be done, but what you've proposed won't by itself solve the issue. If the goal is to make fragments fully modular, I think you'd do well to work through as many counterexamples as you can for your proposal.

How would you prevent this?

query Query {
  user {
    ...SmallUser
    ...BigUser
  }
}

fragment SmallUser on User {
  ...ProfileImage(size: 10)
}

fragment BigUser on User {
  ...ProfileImage(size: 100)
}

fragment ProfileImage($size: Int!) on User {
  imageUrl(size: $size)
}

In short: GraphQL is already not modular with respect to fragments. This proposal is not trying to solve all modularity problems, but to make it possible to solve some of them (primarily, allowing fragments to be used without an operation needing to know about that fragment's variables directly).

There are probably a series of modifications we could make to the language to get GraphQL to be truly modular, but that's outside this RFC's scope.

ivome · 2021-06-10T12:07:44Z

How would you prevent this?

This particular case would be prevented by the rules defined for field selection merging: https://spec.graphql.org/June2018/#sec-Field-Selection-Merging

In short: GraphQL is already not modular with respect to fragments. This proposal is not trying to solve all modularity problems, but to make it possible to solve some of them (primarily, allowing fragments to be used without an operation needing to know about that fragment's variables directly).

There are probably a series of modifications we could make to the language to get GraphQL to be truly modular, but that's outside this RFC's scope.

I agree, GraphQL is not 100% modular and it would require major changes to make it that way. What I'm proposing here is related to a similar point that @leebyron raised in his latest comment on your PR graphql/graphql-js#3152:

"Unique variable names" - should a fragment variable be able to name override another variable?

In other words, should this document be valid? And if it is valid, what do we consider the type of $var in field(arg: $var)?
query Example1($var: String!) {
  ...frag(var: $var)
}
fragment frag($var: String) on Query {
  field(arg: $var)
}

If we allow variable names and types to be overridden in fragments, we remove the dependency between fragment and query variable definitions, and could also allow fragments to be used multiple times in different parts of the query with different variables (what I described above).

mjmahone · 2021-06-10T15:28:30Z

@ivome unfortunately, I know of at least two GraphQL implementations that could be made to support this more-restricted version of the spec change, but could not, without GraphQL response-format changes, be made to support the looser version you're suggesting.

While I recognize that's an implementation detail, I think it would be a bit of a tragedy if the first version of this new syntax could have enabled clients to be spec-compliant in full support of fragment variables, but because we didn't include an extra validation rule, cannot be.

Basically: I'd rather allow GraphQL implementations to support more than the spec by ignoring certain validation rules, than prevent existing spec-compliant implementations from supporting a future spec because we didn't include enough validation rules. Once we're at the point of fragment variables existing, in a very restricted format, in the spec, it becomes easier to provide a pathway for those other implementations to iterate and drop some validation rules that we no longer want to require.

netlify · 2023-01-02T21:49:53Z

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	`c988b54`
🔍 Latest deploy log	https://app.netlify.com/sites/graphql-spec-draft/deploys/63bf250c03aa0800092b13bd
😎 Deploy Preview	https://deploy-preview-865--graphql-spec-draft.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

rivantsov · 2023-01-03T07:36:15Z

spec/Section 2 -- Language.md

-referenced in a fragment and is included by an operation that does not define
-that variable, that operation is invalid (see
+Variables can be used within fragments. Operation defined variables have global
+scope with a given operation, so a variable used within a fragment must either


Operation-defined variables ... ... within the operation

rivantsov · 2023-01-03T07:38:54Z

spec/Section 2 -- Language.md

+Directives[Const]?
+
+Fragments may define locally scoped arguments, which can be used in locations
+that accept variables. This allows fragments to be re-used while enabling the


reused (no dash)

rivantsov · 2023-01-03T07:42:04Z

spec/Section 2 -- Language.md

+}
+```
+
+In this case, the `user` will have a larger `profilePic` than those found in the


not sure but I don't think you need comma after 'In this case'

rivantsov · 2023-01-03T07:44:38Z

spec/Section 2 -- Language.md

+
+The profilePic for `user` will be determined by the variables set by the
+operation, while `secondUser` will always have a profilePic of size 10. In this
+case, the fragment `variableProfilePic` uses the operation defined variable,


operation-defined

rivantsov · 2023-01-03T07:45:46Z

spec/Section 2 -- Language.md

+operation, while `secondUser` will always have a profilePic of size 10. In this
+case, the fragment `variableProfilePic` uses the operation defined variable,
+while `dynamicProfilePic` uses the value passed in via the fragment spread's
+argument `size:`.


do you need colon after size?

rivantsov · 2023-01-03T08:01:03Z

spec/Appendix B -- Grammar Summary.md

+
+FragmentArgumentDefinition : Description? Variable : Type DefaultValue?
+Directives[Const]?
+


So we introduce FragmentArgumentDefinition instead of reusing VariableDefinition just because we want to add Description as well? How about simply adding Description to Variable definition - let's discuss it. If Description makes sense here then it makes sense in Operation variable definition (even more I think)

I tried creating an implementation where we reuse VariableDefinition, and it turned out to be more clunky than this. Fragment argument definitions need to be described everywhere as being argument definitions, not as defining a variable. It causes confusion when referring to a fragment argument's variable definition, IMO. Furthermore, in the actual implementation in graphql-js, the AST refers to arguments in the same way that a field or directive has arguments. When those arguments are defined via variable definitions, you end up over-visiting the VariableDefinition values and needing to check the context of those definitions more than if you have a unique AST value for fragment arguments.

If I could, I would have reused InputValueDefinition: logically, fragment argument definitions produce the same kind of thing in the language as field argument definitions, directive argument definitions, and input object field definitions. Ideally, I would have had FragmentArgumentDefinition : $ InputValueDefinition. This doesn't work, though, as InputValueDefinition is defined as InputValueDefinition : Description? Name : Type DefaultValue? Directives[Const]?.

I could be swayed that it makes sense to reuse VariableDefinition, so long as we don't need to update the text to describe them as anything other than argument definitions in the same way that field arguments are argument definitions in the Spec description. However, another advantage to separating the two is that we probably do not want a directive that is allowed on VARIABLE_DEFINITION to automatically be allowed on FRAGMENT_ARGUMENT_DEFINITION and vice-versa.

On the Description front, agree it probably makes sense to add Description to Operation VariableDefinition, but even so I think FragmentArgumentDefinition makes sense to separate as it is defining an input as opposed to VariableDefinition, which defines a globally available value.

rivantsov · 2023-01-03T08:08:41Z

spec/Section 5 -- Validation.md

+```
+
+the response will have two conflicting versions of the `doesKnowCommand` that
+cannot merge.


in what sense 'cannot merge'? I can write implementation that merges them. The fields have different values I guess. Would be better 'should not merge'?

In the same sense as above,

However, the field responses must be shapes which can be merged

rivantsov · 2023-01-03T08:13:15Z

spec/Section 5 -- Validation.md

+One strategy to resolving field conflicts caused by duplicated fragment spreads
+is to short-circuit when two fragment spreads with the same name are found to be
+merging with different argument values. In this case, validation could short
+circuit when `commandFragment(command: SIT)` is merged with


again 'short circuit' but now without dash.

rivantsov · 2023-01-03T08:16:20Z

spec/Section 5 -- Validation.md

 ```

-the following is invalid since `command` is not defined on `DogCommand`.
+the following is invalid since `command:` is not defined on


command: -> command argument

rivantsov · 2023-01-03T08:19:01Z

spec/Section 5 -- Validation.md


 ```graphql counter-example
 fragment invalidArgName on Dog {
  doesKnowCommand(command: CLEAN_UP_HOUSE)
 }
 ```

+and this is also invalid as `$dogCommand` is not defined on fragment


$dogCommand -> dogCommand argument

rivantsov · 2023-01-03T08:20:39Z

spec/Section 5 -- Validation.md

 ```

-the following is invalid since `command` is not defined on `DogCommand`.
+the following is invalid since `command:` is not defined on


Capital T at sentence start

rivantsov · 2023-01-03T08:24:45Z

spec/Section 5 -- Validation.md

@@ -1828,6 +1891,29 @@ fragment isHouseTrainedWithoutVariableFragment on Dog {
 }
 ```

+Fragment arguments can shadow operation variables: fragments that use an
+argument are not using the operation defined variable of the same name.


operation-defined (dash)

rivantsov · 2023-01-03T08:27:50Z

spec/Section 5 -- Validation.md

+
+because
+{$atOtherHomes} is only referenced in a fragment that defines it as a 
+locally scoped argument, the operation defined {$atOtherHomes}


operation-defined

rivantsov · 2023-01-03T08:31:57Z

spec/Section 5 -- Validation.md

+**Explanatory Text**
+
+All arguments defined by a fragment must be used in that same fragment. Because
+fragment arguments are scoped to the fragment they're defined on, if the


they're - bad style to use these speech shortcuts in documents, change to 'they are'

rivantsov · 2023-01-03T08:33:01Z

spec/Section 5 -- Validation.md

+
+All arguments defined by a fragment must be used in that same fragment. Because
+fragment arguments are scoped to the fragment they're defined on, if the
+fragment does not contain a variable with the same name as the argument, then


maybe simply 'fragment does not use the argument' ?

Probably. I'll change it but we're not explaining the "local scope" well (as a variable being used by an operation includes any recursive fragments, but in this case use means excluding recursive fragments).

rivantsov · 2023-01-03T08:36:38Z

spec/Section 5 -- Validation.md

+fragment does not contain a variable with the same name as the argument, then
+the argument is superfluous.
+
+For example the following is invalid:


add comma after 'For example'
https://linguaholic.com/linguablog/comma-after-for-example/

rivantsov · 2023-01-03T08:38:27Z

spec/Section 5 -- Validation.md

+}
+```
+
+This document is invalid because even though `fragmentArgUnused` is spread with


'is A spread' (currently 'spread' sounds like a verb)

Under "Fragment Spread is Possible", spread is used as a verb:

Fragments are declared on a type and will only apply when the runtime object type matches the type condition. They also are spread within the context of a parent type.

I think we use spread as a verb explicitly: spreading is the action that you take when applying a fragment spread.

rivantsov

looks good, with few comments

rivantsov · 2023-01-03T08:52:18Z

spec/Section 5 -- Validation.md

+cannot merge.
+
+One strategy to resolving field conflicts caused by duplicated fragment spreads
+is to short-circuit when two fragment spreads with the same name are found to be


not sure what short-circuit means

I'm going to update the algorithm to explicitly fail if two spreads with the same name have different arguments, rather than using a "short circuit" (stop early) option.

AnthonyMDev · 2023-01-06T01:07:40Z

I'm really excited for this to make it across the finish line! Great work @mjmahone!

I have read all of the discussions above and in the graphql-js PR regarding the fragment argument uniqueness rule, and I agree with @mjmahone that allowing multiple fragment spreads of the same fragment with different arguments on the same object, would require response format changes and a lot more work to implement. But I'm not clear why are aren't allowing them on different objects?

This would be problematic:

query Query($large: Int!, $small: Int!) {
  user {
    ...ProfileImage(size: $large)
    ...ProfileImage(size: $small)     
  }
}

fragment ProfileImage($size: Int!) on User {
  imageUrl(size: $size)
}

But, unless I have missed something, it looks like this example, given by @ivome, would also be invalid:

query Query($large: Int!, $small: Int!) {
  user {
    ...ProfileImage(size: $large)
     friends {
       ...ProfileImage(size: $small)
     }
  }
}

I'm not sure why that is the case. Fulfilling the fragment on different objects should not cause any issues that I have been able to think of so far. The spec already discusses the concept of different objects not needed fields to merge. This should not require the response format to need any changes. I don't have any reason to believe this makes supporting this new feature in other libraries significantly harder.

@mjmahone The example you give in this comment would be invalid, because there would be a field merging collision in https://spec.graphql.org/June2018/#sec-Field-Selection-Merging, as @ivome stated. As long as field merging is still valid, I don't see why this should be disallowed.

This operation should still be invalid if the fragment is defined in a way that would cause a field merging violation:

query Query($large: Int!, $small: Int!) {
  user {
    ...ProfileImages(size: $large)
    friends {
      ...ProfileImages(size: $small)     
    }
}

fragment ProfileImages($size: Int!) on User {
  imageUrl(size: $size)
  friends {
    imageUrl(size: $size)
  }
}

This would be invalid because when completing field merging the query.user.friends.imageUrl(size:) field would have two different variable values. But this should be part of field merging validation.

Am I mistaken, and this does work the way I'm hoping, or are there other counterexamples that make this problematic?

mjmahone · 2023-01-06T02:54:27Z

Ah @AnthonyMDev the spec/graphql-JS changes as they exist TODAY would allow merging fragment spreads with different arguments at different levels of the response. It reuses the field merging logic.

My comment from 2021 is outdated! How you want it to work is also how I want it to work. But thanks for the example: I will add a test for the example where the field merging needs to fail despite spreads being on different objects.

AnthonyMDev · 2023-01-06T08:03:06Z

That's great news! Thanks for all of this. Can't wait to be able to start using this in Apollo!

martinbonnin · 2023-01-11T10:08:03Z

rfcs/FragmentArguments.md

+If we were writing the language from scratch, I'd advocate for making _all_
+argument definitions without a default value to be required, regardless of their
+nullability. If you want to make a nullable argument optional, you do so by
+adding a `= null` to its definition.


That doesn't work really well either. If you do

fragment Bar($x: Int = null) { number(x: $x) }

then what would $x be in ...Bar? Would it be null or undefined? To be consistent with other default values, I'd expect it to be null but then there's no way to pass undefined (no value).

Not sure what a good solution would be. Maybe add a undefined keyword and allow a subset of union types...

fragment Bar($x: Int | undefined)

I think allowing undefined variables was a mistake :)

However, the reason this version is labelled as an alternative is because it would try to fix that mistake in one place (fragment arguments) and not elsewhere (operation variables, field/directive arguments, input objects). At the very least we'd want to unify with either operation variables or (field/directive arguments and input objects). Since fixing the mistake of undefined inputs is outside the scope of this feature, I'm opting to keep the same behavior we already have (namely, unset gets resolved to either the fragment defined argument default value, or, if there is no default and the variable is nullable, resolves to null or the field defined argument default value).

I think allowing undefined variables was a mistake :)

Gotcha 👍 I think I agree. I cannot think of a use case where a undefined variable or field argument is used (but would be interested to learn about them if any).

For the sake of consistency, I'd rather keep the same behaviour as operation variables though. It took me enough time to understand how it was working that I don't want to learn something new for fragments 😅

mjmahone · 2023-01-11T21:11:39Z

Pulled RFC doc into graphql/graphql-wg#1229 (moved to graphql-wg where RFCs now live).

Note CLA issue was just due to missing an email in my github account. Check should pass on next upload.

mjmahone · 2023-01-19T18:31:34Z

Closing in favor of #1010, as this PR carries a lot of historical baggage that new reviewers don't necessarily need, and has caused confusion.

mjmahone changed the title ~~RFC: Fragment Arguments~~ RFC: Fragment Arguments for Client GraphQL May 5, 2021

IvanGoncharov added the 📣 RFC document PR creates or changes document inside "rfc" folder label May 13, 2021

benjie reviewed Jun 3, 2021

View reviewed changes

rfcs/FragmentArguments.md Outdated Show resolved Hide resolved

michaelstaib mentioned this pull request Jun 3, 2021

Spec: Implement Fragment Arguments ChilliCream/graphql-platform#3785

Closed

leebyron added the 💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md) label Jun 3, 2021

leebyron force-pushed the main branch from de2a1ff to 51337a9 Compare October 26, 2021 23:50

mjmahone mentioned this pull request Dec 19, 2022

Enable Fragment Arguments (a form of parameterized fragments) during execution graphql/graphql-js#3152

Closed

mjmahone changed the title ~~RFC: Fragment Arguments for Client GraphQL~~ RFC: Fragment Arguments (parameterized fragments) for GraphQL Jan 3, 2023

rivantsov reviewed Jan 3, 2023

View reviewed changes

martinbonnin reviewed Jan 11, 2023

View reviewed changes

mjmahone closed this Jan 11, 2023

mjmahone force-pushed the rfc-fragment-arguments branch from 3a458c3 to e736f78 Compare January 11, 2023 19:07

mjmahone and others added 6 commits January 11, 2023 14:18

Fragment Arguments added to spec

16be477

text changes

1b580c8

Address Roman's comments

9b534d9

operation-defined

03bf02e

Updated RFC doc to prep for WG

768ca34

Updated RFC doc: explanation on required vs nullable

aef355c

mjmahone reopened this Jan 11, 2023

mjmahone mentioned this pull request Jan 11, 2023

RFC: Fragment Arguments graphql/graphql-wg#1229

Merged

Split RFC doc into graphql-wg PR

c988b54

graphql deleted a comment from linux-foundation-easycla bot Jan 11, 2023

mjmahone mentioned this pull request Jan 11, 2023

RFC: Fragment Args defined as Variable Definition mjmahone/graphql-spec#2

Open

mjmahone mentioned this pull request Jan 19, 2023

Fragment Arguments: Spec Implementation #1010

Closed

mjmahone closed this Jan 19, 2023


		FragmentArgumentDefinition : Description? Variable : Type DefaultValue?
		Directives[Const]?

RFC: Fragment Arguments (parameterized fragments) for GraphQL #865

RFC: Fragment Arguments (parameterized fragments) for GraphQL #865

Conversation

mjmahone commented May 5, 2021 • edited Loading

Overview

Background

andimarek commented May 5, 2021

mjmahone commented May 6, 2021 • edited Loading

IvanGoncharov commented May 13, 2021

mjmahone commented Jun 2, 2021

ivome commented Jun 9, 2021

mjmahone commented Jun 10, 2021

ivome commented Jun 10, 2021

mjmahone commented Jun 10, 2021

netlify bot commented Jan 2, 2023 • edited Loading

✅ Deploy Preview for graphql-spec-draft ready!

rivantsov Jan 3, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mjmahone Jan 3, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rivantsov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AnthonyMDev commented Jan 6, 2023 • edited Loading

mjmahone commented Jan 6, 2023 • edited Loading

AnthonyMDev commented Jan 6, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mjmahone commented Jan 11, 2023 • edited Loading

mjmahone commented Jan 19, 2023

mjmahone commented May 5, 2021 •

edited

Loading

mjmahone commented May 6, 2021 •

edited

Loading

netlify bot commented Jan 2, 2023 •

edited

Loading

rivantsov Jan 3, 2023 •

edited

Loading

mjmahone Jan 3, 2023 •

edited

Loading

AnthonyMDev commented Jan 6, 2023 •

edited

Loading

mjmahone commented Jan 6, 2023 •

edited

Loading

mjmahone commented Jan 11, 2023 •

edited

Loading