graphql / graphql/graphql-spec

Literal aliases (not necessarily fields)

Open
#165 3 comments 0 reactions 0 assignees View on GitHub
👻 Needs Champion 💤 stale ? 💭 Strawman (RFC 0)
Dominant language
JavaScript
Stars
14.6k
Forks
1.2k
PR merge metrics
No merged PRs in 30d

Description

(I'm building a GraphQL query service outside the context of Relay, just as an interesting retrieval specification layer for API which might be machine-to-machine as well as GUI-driven.)

Given than an object may implement multiple interfaces, if a collection is of a union of types (like subclasses of a superclass) there is not necessarily a long-term-stable type id for each object in the collection that a client can use. As a simple example, you may have physical and non-physical items in your shopping basket: all have id, description, and price, but only physical items have pictures. Pets are physical items that have lifespans. (We're not shipping pets, this is for in-store use only.) A pet is both animal and physical item.

To put the client fully in charge of what it cares about for type identification, one vehicle would be to allow the client to specify literals for aliases. I'm not saying there aren't other ways to handle this particular use case, only that this illustrates a single use case for the capability. In the following, one request can see 'physical' as the type for cart contents, while another could see 'pet' called out specifically.

This is completely analogous to selecting constant column expressions in SQL, eg. `select 'foo' from myTable`

```
{
cartContents {
id description price
type : 'generic'
... on physicalItem {
picture (size: 'small')
type: 'physical'
}
}
```

vs

```
{
cartContents {
id description price
type : 'generic'
... on physicalItem {
picture (size: 'small')
type: 'physical'
... on pet {
type: 'pet'
age
}
}
}
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.