GraphQL schema design for analytics platform

Question

I am just starting to explore GraphQL as an option for my API level analytic platform.

My user interface is mainly built from tables and diagrams. in most cases, the data is some database columns grouped by size.

I found the following article https://www.microsoft.com/developerblog/2017/09/28/data-independent-graphql-using-view-model-based-schemas/ from Microsoft, describing their approach to how to develop GraphQL schemas (see below).

type Query { channels(source: String!, query:String!, appId:String!, apiKey:String!): [Channel] lineCharts(source: String!, query:String!, appId:String!, apiKey:String!, filterKey:String, filterValues:[String]): [LineChart] pieCharts(source: String!, query:String!, appId:String!, apiKey:String!): [PieChart] barCharts(source: String!, query:String!, appId:String!, apiKey:String!, filterKey:String, filterValues:[String]): [BarChart] } type Channel { name: String id: Int } type LineChart { id: String seriesData : [Series] } type PieChart { id: String labels: [String] values: [Int] } type BarChart { id: String seriesData : [Series] } type Series { label: String x_values: [String] y_values: [Int] } 

It seems to me that this design is strict, forcing any new schedule to be added to the root query. How can a schema be more general without losing the benefits of GraphQL?

Answer 1

You can do something with union types and inline/fragments

 union Chart = LineChart | PieChart | BarChart type Query { charts( source: String! query: String! appId: String! apiKey: String! filterKey: String filterValues: [String] ): [Chart] } 

Then you can force your charts converter to charts ALL charts and write your queries, for example

 fragment Identifiers on Chart { __typename id } query { charts(...) { ...on LineChart { ...Identifiers seriesData } ...on PieChart { ...Identifiers labels values } ...on BarChart { ...Identifiers seriesData } } } 

Identifiers will provide you with some information about the type you are dealing with and id , but you can expand it to what you like if these fields are common to all types in this union (or you can extend it only to some of types).

There are two ways that you can deal with if you do not want to enter all the diagrams:

• Add inline snippets only for the types you want, but the rest will still be present as empty objects.
• Pass another argument to the resolver representing the type / s you want

PS You can get as granular as you like, there are also interfaces and input types .