mjmahone
commented
5 years ago For a single server schema, I'm not yet convinced this adds a lot of value: you still need to actually implement each field on each concrete type (unless you're using inheritance and a language that supports that, I guess). I also personally find it valuable to be able to look up a schema definition and immediately see all the fields on it. That may be solvable in tooling like GraphiQL, though.
However I can understand this being painful when you're coordinating multiple schema definitions (such as client-side type extensions): in this case you can end up in "schema deadlock" with the current validation rules. As an example, let's look at an evolution of a schema with both server and client definitions.
Server schema:
interface Pet {
name: String
}
type Dog implements Pet {
name: String
}
type Cat implements Pet {
name: String
}Client schema
extend interface Pet {
sound: String
}
extend type Cat {
sound: String
}
extend type Dog {
sound: String
}If we add a new type on the server:
type Ferret implements Pet {
name: String
}the client schema extensions are now invalid, because there is no client extension (yet) for Ferret. But we made a compatible change, based on our current validation rules.
I'm not sure the best way to solve this. I'm solving it for my project by allowing interface extensions to automatically extend concrete types. But I don't know if there's another way to do it, or whether that should extend to interface definitions, too.
Which is a long-winded way of saying: there is probably value in someone championing a change in this space.
dancon
mdecurtins
voxpelli
benjdlambert
martinbonnin
NavidMitchell
micchickenburger
benjie
rivantsov
If an interface contains more than a few properties and is used in multiple places, you end up with a very significant amount of repetition that clutters up your schema. This means it requires a lot more scrolling to move around the schema, and the important details of a type (eg which properties are unique to it) are obscured by the noise added by all of the extra repetition.
As a contrived example, take the following currently legal schema, similar in structure to what I'm currently working on:
I propose that the following would be valid, and equivalent to the above:
as you can see, even with this relatively simple example, we would be able to cut the number of lines of code in half. Instead of spanning multiple screens, it can now easily fit on a single screen. Each type clearly highlights the attributes which are unique to that type, and if one wants to know what other properties are included, one can easily glance up to see them (or examine the type in GraphiQL).
Furthermore, say I want to add another property to
Vehicle, like saycolor. The way it currently is, that means I have to now remember to also add the property toBicycle,Automobile,Car,MotorcycleandTruck. When I want to change something, the fewer places I have to make a change (and the fewer places I have to remember to change), the better. With the proposed change, I would only need to add thecolorproperty in one place to have it added to allVehicles