Edit
Given the priority of redeployability, the team has made the decision that this will not be considered to be included as an official API provided by services until after the first redeployable release. This is to ensure that work on GraphQL does not block or impede momentum on redeployability.
As such, I am re-proposing a solution for using GraphQL only from our web application, which is being developed parallel to the taskcluster-tools redeployable instance. Commentary that takes this into account starts at #96 (comment).
End Edit
From http://graphql.org/:
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
Why?
The Tools site fetches an enormous amount of data to display some tools. We have things like continuation tokens to limit the number of records, but nothing to control on a fine-grain level what data we can request from particular APIs. Up until now, the most useful premise is when requesting a resource is to throw everything that a user may need to avoid subsequent requests, but this is becoming hard to manage on the front-end.
When requesting a list of tasks from a group, what if I could say I only wanted the name and task status from each task? GraphQL can do that.
What if I want to fetch a list of tasks, but also a selected task, in a single request? GraphQL can do that, too.
I'm not sure if this is feasible, but I think this has at least some merits for discussion, and could be a good path forward to making inroads to the network performance for our front-end.
Edit
Given the priority of redeployability, the team has made the decision that this will not be considered to be included as an official API provided by services until after the first redeployable release. This is to ensure that work on GraphQL does not block or impede momentum on redeployability.
As such, I am re-proposing a solution for using GraphQL only from our web application, which is being developed parallel to the taskcluster-tools redeployable instance. Commentary that takes this into account starts at #96 (comment).
End Edit
From http://graphql.org/:
Why?
The Tools site fetches an enormous amount of data to display some tools. We have things like continuation tokens to limit the number of records, but nothing to control on a fine-grain level what data we can request from particular APIs. Up until now, the most useful premise is when requesting a resource is to throw everything that a user may need to avoid subsequent requests, but this is becoming hard to manage on the front-end.
When requesting a list of tasks from a group, what if I could say I only wanted the name and task status from each task? GraphQL can do that.
What if I want to fetch a list of tasks, but also a selected task, in a single request? GraphQL can do that, too.
I'm not sure if this is feasible, but I think this has at least some merits for discussion, and could be a good path forward to making inroads to the network performance for our front-end.