Proposal: (Un)folding aliases

[esseswann]

I like concept of aliases very much because they allow to abstract components from request, which is especially useful when backend is agnostic about specific client implementation or under heavy development

But there is another aspect of client-server data structure controversy: nesting

To make client even more independent from server schema implementation I propose these enhancements:

To get a deeply nested value

node {
  alias: subnode.subnode.field
}

To put some values from the node under an alias

node {
  nodeField1
  nodeField2
  alias: {
    nodeField3
    nodeField4
  }
}

This would allow to quickly reshape queried data in declarative way while keeping the query concise and obvious

[stubailo]

I think aliases have exactly one irreplaceable function: they allow you to query the same field twice, but with different arguments. I think the ability to rename fields is a nice side effect.

Right now GraphQL is only focused on requesting data, and this would move it towards a request/transformation combo, which would probably lead in the direction of more features and make the language a lot more complex. I would suggest using a client-side library to transform the data before passing it to your UI, for example recompose for React, or Apollo Client's built in props transformation.

[esseswann]

Thnx for reply.
I agree that you can definitely transform on client before passing it to UI components but it has disadvantages:

• more middleware computing on client
• communication is not declarative
• less drop-in usage of pure components

I agree that current proposed syntax might be naive yet restructuring is the first thing you do after receive data. I would like to hear from other developers if that's a scenario.

[stubailo]

I just think it's also good to keep in mind the disadvantages of making the GraphQL language more complex to include features for data transformation. IMO the API layer should be as simple as possible and complexity pushed to the edges.

[smolinari]

But there is another aspect of client-server data structure controversy: nesting.
To make client even more independent from server schema implementation...

@esseswann - could you please elaborate a bit more on the problems your suggestion could solve?

My request is more for my own understanding, but also maybe others could chime in with possible solutions, which might work without making GraphQL more complex. I agree with Sashko. Making the API more complex should be avoided.

Scott

[esseswann]

@smolinari Valid request and this proposal does come from some difficulties I met during developing with react-apollo. Here is a simplified example:
So you often have such query

human {
  name
  nickname
  eyeColor
  hairColor
}

And you want to render it in this way:

If there is a lot of fields in human you will have to create a config to map it to data for each section
On the contrary you often have such structure

human {
  worksAt { address { city } }
}

And obviously you just need that little string on the top level but will have to transform the result.
In my team we are very often performing these tasks

[calebmer]

Given this and other proposals that use dot syntax (#174, #248) which may be easily implemented client side. How about we instead create one proposal which reserves dot syntax space so clients like Apollo could extend the parser to add support for this while not adding unnecessary complexity to servers?

[esseswann]

@calebmer Non dot syntax like for example alias: worksAt { address { city } } or with some special symbol like alias > worksAt { address { city } } might lead to problems with fragments

It would have a real value implementing it server side for obvious performance reasons

[sorenbs]

We have a use case for To put some values from the node under an alias

We allow our developers to sync their data to external services such as Algolia. To specify what part of the data they want synced they specify a graphql query.

Algolia has a strict requirement about how to format the data to enable geo search functionality. This feature would allow our developers to directly use graphql instead of us introducing explicit support:

node {
  _geoloc: {
    lat,
    lng
  }
}

I don't know that this is the right direction for GraphQL, but the use cases are obvious rom my perspective.

[rmosolgo]

Just brainstorming, another option for "values under an alias" would be an inline fragment + directive:

node {
  ... on Node @geoloc {
    lat 
    lng
  }
}

An intermediary could transform the result.

[esseswann]

By the way this

alias: field(param: 1).subfield.deepField(param: 5)

and even this

alias: field(param: 1).subField {
   id
   deepField
  }

is also intuitive and quite handy

[stubailo]

I do like the dot notation. I guess whenever you request a nested field, you would need to use an alias since otherwise there wouldn't be a good name for it?

Perhaps this is something that could be done in the form of a query transpiler - something that would compile this into a "regular" GraphQL query, then transform the result appropriately as well.

That would allow this feature to be used without modifying the wire protocol or Apollo client. However you still wouldn't easily be able to use query validation tools so in general I'm against extending the syntax unless there is a really good reason.

[esseswann]

@stubailo I myself got a little concern about implementation of such feature. Wouldn't it break the Apollo cache system for example? If restructuring is done on the server then automatic cache update will be difficult

[stubailo]

@esseswann there are two possible approaches:

1. The query is compiled into a regular query at build time, and the GraphQL spec remains unchanged, so Apollo will work as-is
2. This syntax will become part of the spec, in which case we will update Apollo to work with it. This is pretty consistent with how Apollo works already anyway, so it would be a relatively trivial change. (We don't put aliases into the store, so we would inspect the path after the alias to figure out where to put the data)

Unfortunately there isn't something like Babel for transpiling experimental GraphQL syntax so it's hard to implement features like this in a way that many people can try.