Skip to content

GraphQL can be less strict and complicated #932

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
Open
moshest opened this issue Feb 27, 2022 · 20 comments
Open

GraphQL can be less strict and complicated #932

moshest opened this issue Feb 27, 2022 · 20 comments

Comments

@moshest
Copy link

moshest commented Feb 27, 2022 •
edited
Loading

I'm a software engineer for almost 20 years and I recently started using GraphQL extensively.

While I understand the original thoughts of making GraphQL as simple as possible, we end up with a language that's too complicated to handle taking too much control out from the user.

For instance:

  1. Object type seems redundant, we can just use interfaces instead:
interface Query {
  tasks: [Task!]!
}

interface Task {
  name: String!
  done: Boolean
}
  1. input types are just making everything more complicated and harder to share the same interfaces between inputs and outputs. It's better to define a workaround for field input with arguments than making everything duplicated with input types (Ie. ignore fields with arguments on inputs or allow a way to provide field arguments on input queries as well).
interface Mutation {
  addTask(data: TaskData!): Task!
}

interface TaskData {
  name: String!
}

interface Task implements TaskData {
  name: String!
  done: Boolean!
}
  1. In most of my schemas, I end up make more fields as required than I have optional fields. It will be much better to reverse the type system and allow mark only the optional fields instead:
interface Query {
  tasks: [Task]
}

interface Task {
  name: String
  done: Boolean?
}
  1. Adding recursion support for queries: Same as SQL let you run queries that can overwhelm the server, I think GraphQL should enable the same and let the user handle the consequences. Security concerns should only apply on the server implementation and not restrict language abilities.
interface TreeNode {
  label: String
  children: [TreeNode]
}

query {
  getTree {
    ...Node
  }
}

fragment Node on TreeNode {
  label
  children {
    ...TreeNode @RecursionLimit(100)
  }
}

I understand that this may not be the best place to communicate my thoughts but all of those points are shared across the internet with many StackOverflow and questions from frustrated users. If at least a few more people will see and agree with me then we can start pushing for a change in the proper channels.

We love GraphQL, we just want to make it better ❤️
@moshest moshest changed the title GraphQL is too strict and complicated GraphQL can be less strict and complicated Feb 27, 2022
@rivantsov
Copy link
Contributor

rivantsov commented Feb 27, 2022 •
edited
Loading

regarding recursive refs in fragments, this is under discussion:

#929

by the way, in the sample, did you mean "...Node" as fragment spread?

fragment Node on TreeNode {
  label
  children {
    ...Node @RecursionLimit(100)
  }
}

@rivantsov
Copy link
Contributor

Using interfaces instead of 'Object types' - interesting approach, I think it works already as-is, and for backward compatibility we have to keep 'type' forever.
abandoning input types - I doubt it would work, because of the problems of fields with parameters cannot be used in 'inputs' or 'input interfaces'. I think a very good improvement would be to allow input types as return types (Object types). If working with interfaces - server can just allow only interfaces as inputs that are without such parameters fields, without special designation of them as 'input interfaces', and report an error if violated

@benjie
Copy link
Member

benjie commented Mar 1, 2022

Here's some reasons why input (InputObject) and output object (Object) types probably shouldn't be the same thing:

  • Nullability: Changing an Object's field to be non-nullable is a non-breaking change, changing it to be nullable is a breaking change. Conversely, making an InputObject's field nullable is a non-breaking change, but making it non-nullable is a breaking change. Combine these two together (because the type is now both input and output) and you can no-longer change the nullability of the fields, which limits schema evolution options.
  • Field addition: Adding any field to an Object type is a non-breaking change (because GraphQL makes you explicitly state which fields you need, so a new field will not affect any existing queries). Adding a nullable field to an InputObject type is a non-breaking change (a non-nullable field would be a breaking change because it would make all previous operations using this InputObject invalid since this field will not have been supplied). Therefore you'd only be able to add nullable fields to the GraphQL schema, limiting schema evolution options.
  • Symmetry: If you use the same type for input as output then a user might expect to be able to supply an Object that they queried back as input to a future operation; however this may or may not be valid depending on what their selection set was, and as the schema evolves it all but guarantees that people doing this will lose data.
  • Asymmetry: Whereas output objects link to many other types, input objects much more rarely want inputs for these links, so when a link like this wants to be added to an existing type that's used in both input and output much thought will have to be given to whether or not to add the relating field (since it will also affect inputs). This again limits schema evolution options.
  • Cycles: It's perfectly valid for an Object to state that it references itself in a non-nullable way, e.g. type Query { query: Query! }, however a type like this cannot be valid for input due to cycles. Now consider that this cycle might not be between the type and itself but between any types - now you're requiring that the type tree is a directed acyclic graph which seriously limits the usefulness of the type system (e.g. a Post can have an Author, but the Author is not allowed to link back to Posts because that would be a cycle)

I'm sure we can come up with solutions to all these issues (and more) by adding complexity to GraphQL - e.g. making the nullability of a field dependent on whether it's input/output, making some fields input-only or output-only, etc - but the current solution is also the simple solution, i.e. that input types and output types are inherently separate because their concerns do not align.

@romshark
Copy link

  • Cycles: It's perfectly valid for an Object to state that it references itself in a non-nullable way, e.g. type Query { query: Query! }, however a type like this cannot be valid for input due to cycles.

Consider these examples:

# This is fine.
type Query { a: A! }
type A { b: B! }
type B { a: A! name: String! }
query {a{b{a{b{a{b{
 name # cycle is broken
}}}}}}}

However, this schema can't be queried legally:

# this cycle can't be broken and should be illegal
# there is no valid way to query it.
type Query { a: A! }
type A { b: B! }
type B { a: A! }
query {a{b{a{b{a{b{
 a # illegal
}}}}}}}

The spec allows this construct but it really shouldn't.
Probably a topic for another issue though.

@rivantsov
Copy link
Contributor

it's illegal not because of loop of non-null references, but because there are no LEAF type fields!; if you make fields a and b nullable, you still won't be able to construct the query, because there's no field that can end the query!

@romshark
Copy link

it's illegal not because of loop of non-null references, but because there are no LEAF type fields!; if you make fields a and b nullable, you still won't be able to construct the query, because there's no field that can end the query!

That's correct.

What about the input types? I still haven't found the paragraph that explicitly forbids cyclic dependency in input types.

@benjie
Copy link
Member

benjie commented Sep 14, 2022 •
edited
Loading

Your query can be legal, you just need to provide a selection set since a is not a leaf. Here's a valid query:

query {a{b{a{b{a{b{
 a { __typename }
}}}}}}}

@benjie
Copy link
Member

benjie commented Sep 14, 2022

What about the input types? I still haven't found the paragraph that explicitly forbids cyclic dependency in input types.

It's in the "Input Objects" section under the heading "Circular References":

https://spec.graphql.org/draft/#sec-Input-Objects.Circular-References

@benjie benjie mentioned this issue Jul 4, 2023
Closed
@jsshapiro
Copy link

So... There are three glaringly obvious reasons why input and output types should not be distinct:

  1. The partitioning means that data cannot be forwarded. A service cannot accept an input object and then turn around and pass it along as an output object without rewriting the darned thing into a (frequently identical) output object. As an example of why this is important, consider message queues. Which bear a strong resemblance to subscriptions...
  2. The partitioning forces a lot of replicated code at every layer of the software stack. Consider, as an incomplete illustration, the complexity of mapping an existing SQL schema to a corresponding GraphQL schema (and, of course, back, since what gets read eventually tends to get written).
  3. From a formal type system perspective, directionality of I/O is completely orthogonal to type. Formally speaking, the partition of input and output types makes the GraphQL type system unsound (I'm using "unsound" here in a strictly technical mathematical sense, not as a value judgement).

If there is a credible motivating explanation for this division, I haven't seen it. I've looked pretty hard, and if somebody can point me the right way I'd be grateful. The issues that @benjie identifies aren't things that a protocol can fix - they are fundamental to the evolution of the underlying information architecture. I really do understand why being able to rapidly evolve a protocol without going through protocol versioning hell is very appealing. The approach taken by Kenton Vardy with protocol buffers and CapnProto accomplishes a lot of the same goals without breaking the concept of types. In effect, they distinguish usefully between the static and the dynamic type of the object without giving up either.

The separation also adds obscurity to a more fundamental issue that arises from the interaction between the query language and the client cache merging strategy: inconsistency.

Suppose I do a query that requests fields A and B of some object. Later, I do a second query that accepts fields D and C of that same object. There is no reason to believe - and no way to check - that I now have a consistent version of the object in my client cache. It's entirely possible that there have been 85 mutations of the underlying object in the persistent store between these two queries, and that one or more of them modified the A field or the B field. If so, my cached copy on the client now blends two different versions of the object. The very last thing you want to do in this case is send that object back as an update.

This is one of the issues that ultimately made me put GraphQL down. A potential "fix" here, if you want one, is to ensure that all object [fragments] have a version number (or a lastStored field) whether you asked for it or not, and that the version number gets passed in both directions. This wouldn't significantly impeded the ability to expose a third party API through a GraphQL interface. A more extreme approach would make queries persistent, in effect creating a subscription on the server. The challenge with that is that it would require a significant amount of per-client server state, which makes service replication for scaling much harder. Ultimately I suspect this would run fairly hard into some of the scaling issues that Meteor pub/sub ran into.

The other issue that drove me away is that field-level selectivity and statically typed programming languages really play badly together. If all of your client targets are some variant of a browser (potentially including things like electron), great. But a GraphQL API is quite difficult to invoke from, say, C#. In my opinion, GraphQL fits the browser-based client niche extremely well, but there's more to the world than browsers. Which, ironically, is one of the reasons Geoff Schmidt left Meteor to found Apollo GraphQL. As an example, Shopify's adoption of a GraphQL-based API made life very dramatically harder for a large number of clients written in C#.

We've been building APIs since the earliest days of networking - the first API specification language I leraned came from Apollo Computer more than forty years ago. I'm not a fan of discarding new ideas without a clear reason, but skepticism is healthy. GraphQL's type partitioning idea has many strikes against it. The biggest one, from my perspective, is that it is mathematically unsound.

@rivantsov
Copy link
Contributor

rivantsov commented Feb 23, 2024 •
edited
Loading

@jsshapiro ,
agree 100%. Or maybe 99. I tried to push these issues but gave up, it's no use. The guys who make decisions there are absolutely against ANY change.
One question, why are you saying consuming graphql from c# is a trouble/problem? GraphQL client (the one that I have), returns c# types/objects which are partially filled, depending on the query. Yes, this might be inconsistent depending on how you define types' internal consistency rules, but if you accept this as a basic premise - that the returned object fields (any of them) might be just defaults (because they were not listed in query) - then you can go with it just fine.
I have a sizable app, built in web assembly Blazor, and the GraphQL client is a c# component, and all client logic around it is c#. It works great - except occasional situation like "why this new field/control is empty?! - I see value in the database... ah, I forgot to add it to the query".

@rivantsov
Copy link
Contributor

rivantsov commented Feb 23, 2024 •
edited
Loading

ah, and about input types and mutations - in my app. There are around 40 types to be loaded/updated, so we recognized a problem from the start - we didn't want to define extra 40+ input types and mutations, so we came up with a concept of 'one mutation', using one update endpoint, when you send a list of update packs, each is ObjectType and list of field-newValue pairs. we integrated it with server-side ORM, using mapping to entities which is already there for querying.
So now adding a type does NOT need any extra input types and new mutation endpoints. I think this might be actual solution for this input types conundrum; hell with the spec, we have a nice workaround. (by the way, building an update pack from input form - fully automatic, c# code running thru model and comparing field values)

@valenterry
Copy link

Here's some reasons why input (InputObject) and output object (Object) types probably shouldn't be the same thing:

* Nullability: Changing an Object's field to be non-nullable is a non-breaking change, changing it to be nullable is a breaking change. Conversely, making an InputObject's field nullable is a non-breaking change, but making it non-nullable is a breaking change. Combine these two together (because the type is now both input and output) and you can no-longer change the nullability of the fields, which limits schema evolution options.
* Field addition: Adding any field to an Object type is a non-breaking change (because GraphQL makes you explicitly state which fields you need, so a new field will not affect any existing queries). Adding a _nullable_ field to an InputObject type is a non-breaking change (a non-nullable field would be a breaking change because it would make all previous operations using this InputObject invalid since this field will not have been supplied). Therefore you'd only be able to add nullable fields to the GraphQL schema, limiting schema evolution options.

This is actually a solved problem in the type-system of many programming languages. The relevant term here is variance. In this example, the type of the input would be contravariant (= client needs to use exact input type or something less specific), whereas the type of the output would be covariant (= server needs to return that exact input or something more specific).

Instead of reinventing the wheel, we should learn from other languages that already solved this. Here is an example.

* Symmetry: If you use the same type for input as output then a user might expect to be able to supply an Object that they queried back as input to a future operation; however this may or may not be valid depending on what their selection set was, and as the schema evolves it all but guarantees that people doing this will lose data.

When correctly applying variance rules, then it is indeed possible for the client to do this! So this is not a problem. Or put in other words: when using the same type as an input and output type, then making a field nullable is a breaking change because it violates the covariance rules (i.e. the server response could break the client).

However, certain changes will be possible. Such as adding a new field that is nullable. This is not breaking any variance rule.

* Asymmetry: Whereas output objects link to many other types, input objects much more rarely want inputs for these links, so when a link like this wants to be added to an existing type that's used in both input and output much thought will have to be given to whether or not to add the relating field (since it will also affect inputs). This again limits schema evolution options.

I believe you are mainly thinking about the primary input and return type. However, imagine using dedicated input and output types, while having these types contain (= reuse) other types. This is very often a great compromise.

I'm sure we can come up with solutions to all these issues (and more) by adding complexity to GraphQL - e.g. making the nullability of a field dependent on whether it's input/output

This would indeed add complexity and be a bad idea. I think it's much better to remove currently already existing complexity by using better concepts as a foundation that automatically allow the use cases described by the OP.

@jsshapiro
Copy link

jsshapiro commented Mar 23, 2025 via email

@jsshapiro
Copy link

jsshapiro commented Mar 23, 2025 via email

@martinbonnin
Copy link
Contributor

@jsshapiro can you ellaborate on why you're saying the GraphQL type system is "unsound"?

My current understanding of "soundness" in a type system relates to the fact that the type at build time matches the runtime one (said it otherwise, "if it builds, it runs"). I think this applies to GraphQL as well? The fact that input and output types are separated doesn't necessarily make GraphQL "unsound"? Or does it?

For some context, Here is a proof that Kotlin is "unsound" I recently bumped into. But I fail to find a matching example for GraphQL.

Do you have an example/proof that the GraphQL type system is unsound?

@jsshapiro
Copy link

jsshapiro commented Mar 24, 2025 via email

@martinbonnin
Copy link
Contributor

@jsshapiro thanks for the quick reply!

I didn't say that the GraphQL type system is unsound

You did there:

Formally speaking, the partition of input and output types makes the GraphQL type system unsound (I'm using "unsound" here in a strictly technical mathematical sense, not as a value judgement).

Since I learnt about "unsoundness" recently, I was curious to learn more about it. But I agree with you that it doesn't really apply to GraphQL as GraphQL isn't describing programs.

As for your other points, I disagree that GraphQL is not cacheable. You can use persisted queries and basically turn your GraphQL API into a very cacheable REST API. Client side normalized caches also help.

I'm intrigued by the HTTP2 streaming possibilities. Maybe there's something that GraphQL could do better there? In which case a separate, more focused issue would help a ton! Same for input/output disymmetry. It feels a bit of an oddity but I'm sure there are tradeoff involved and a focused discussion would help (if there is not one already!).

@jsshapiro
Copy link

jsshapiro commented Mar 24, 2025 via email

@martinbonnin
Copy link
Contributor

For caching, if using persisted queries/trusted documents + HTTP GET, you can store a lot of things in your CDN. I've been doing that in Confetti. And while the traffic is nowhere near a real world website, the query responses are served from the edge in a few milliseconds.

Obviously, caching is one of the most difficult thing in computer science so it's all tradeoffs, etc.. And GraphQL being very dynamic can make things look more complicated. But there are solutions out there. And if PQs + client side cache is not enough, you can also do entity-caching in your API gateway, etc...

At the end of the day, GraphQL shares a lot of caching characteristics with REST. GraphQL + persisted queries is just REST where the client gets to build its own endpoints on demand without having to bother a backend engineer.

@valenterry
Copy link

GraphQL (at least for now) doesn't have subtyping, so the covariance/contravariance issue does not arise in the usual way. Adding inheritance would change this. But there's a similar problem hiding in the notion of non-breaking changes. Here's an example that benjie gave in issue 932:

It does have subtyping though. The main aspect of subtyping is substitutability. Therefore, the fact that you can substitute a nullable type (X) with an non-nullable type (X!) in the response(!) without breaking the schema is proof of that. You can find similar examples in the official spec.

The same is true for interfaces, unions and so on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@benjie @moshest @rivantsov @valenterry @martinbonnin @romshark @jsshapiro