{"id":4575,"date":"2017-09-28T10:02:12","date_gmt":"2017-09-28T17:02:12","guid":{"rendered":"https:\/\/www.microsoft.com\/reallifecode\/?p=4575"},"modified":"2020-03-14T19:59:34","modified_gmt":"2020-03-15T02:59:34","slug":"data-independent-graphql-using-view-model-based-schemas","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/ise\/data-independent-graphql-using-view-model-based-schemas\/","title":{"rendered":"Creating a Data Visualization GraphQL Server with a Loosely Coupled Schema"},"content":{"rendered":"

We recently built a dashboard for visualizing data<\/a> from\u00a0Application Insights<\/a>. This Azure service enables the collection of large amounts of information about an application’s business analytics and health, plus quick and efficient access to that data by using Kusto Query Language<\/a>. For this purpose of building a flexible data visualization dashboard, we explored the GraphQL<\/a> stack, a query language that enables abstraction of server-side API calls under a single neat wrapper instead of multiple endpoints.<\/p>\n

The initial design of Project Ibex<\/a>, our Bot Analytics<\/a> dashboard,\u00a0included a centralized data pipeline using a REST server as a pass-through proxy to return aggregated results from multiple services with a single JSON response. Maintaining our own data service, however, added unnecessary complexity to the Ibex project. Giving the rising popularity of GraphQL, we decided to investigate a design based on this stack. We sought to minimize the existing complexity and optionally gain performance improvement.<\/p>\n

One of the most powerful features of Ibex is the ability for users to specify any Application Insights query when building a new dashboard, without writing a single line of code. However, to use GraphQL, users must define a common schema between their clients and server. Since\u00a0GraphQL requires the client to have access to a defined schema in advance, there may be some considerations when developing with it: for instance, what happens when a project like Ibex needs to support dynamic data representations?<\/p>\n

At first glance, it seems as there is no simple solution to support any<\/em> data and any<\/em> client-provided query while keeping the schema loosely coupled with the data representation. In this blog post, we will share our learnings from this challenge, including how we leveraged the GraphQL stack and came up with a smart yet simple solution.<\/p>\n

<\/p>\n

Rethinking GraphQL schemas<\/h2>\n

\"Image
Project Ibex – Screenshot<\/figcaption><\/figure><\/p>\n

While we could have worked around GraphQL’s dynamic schema limitations by supporting a predefined set of queries, this approach would have limited the reusability of Ibex and increased long-term maintenance complexity.<\/p>\n

Another workaround would have been to declare a generic schema GraphQL, as follows:<\/p>\n

\/\/ #### NOT recommended approach ####\r\n\r\ntype Query {\r\n  generalQuery(query: String!): JsonResponse\r\n}\r\n\r\ntype JsonResponse {\r\n  body: String\r\n}\r\n<\/pre>\n
The results contain a single field ‘JsonResponse’<\/em> and it is the client’s responsibility to parse, process and visualize it. The above solution, enables dynamic schema support at the expense of GraphQL benefits, reducing GraphQL into an expensive REST server with no additional benefits.<\/p>\n
With a generalized schema:<\/p>\n