Why We Advised Our Customer Against GraphQL

DZone 's Guide to

Why We Advised Our Customer Against GraphQL

APIs are crucial to the ways developers access and use data. Read on for a discussion of why one team advised against the use of GraphQL to ingest data from APIs.

· Big Data Zone ·
Free Resource

GraphQL has captured a lot of developer interest over the last year or so with many production level systems making the switch from REST type APIs to GraphQL. When one of our existing customers asked us to decide if we should switch their existing APIs over to GraphQL, the team was pretty excited to finally get to work on this new style of API calls!

However, as we evaluated the technology and assessed its compatibility with the existing system, we decided to not make the switch. Here is the case in consideration!

The Existing System

  • SQL Server DB with SPs, functions, views, and queries. SPs are non-modular in the sense they join various tables and return values specific to the calls being made.
  • Connection with the DB is using basic ADO.NET and not with EF/LINQ, etc.
  • ASP.NET WebAPI2.0 (Not .NET Core) and Java-based APIs.
  • Native Android, iOS and Web Clients. Some portion of the web clients bypasses the API and talks to the DB directly.
  • WebClients: ASP.NET and React.
  • A React Native-based app.

System Maturity

  • System has been in production for few years now and is stable.
  • As the system is in a competitive space, new features are always getting added apart from usual maintenance.

Customer Ask

  • Whether it makes sense to wrap our existing APIs into a GraphQL Endpoint.
  • For a new feature in the react app evaluate making the new .NET based APIs in GraphQL.

There is not much documentation on implementing GraphQL servers. Most tutorials etc. focus on GraphQL clients or at most JavaScript and .NET Core servers. Apollo GraphQL, which is typically used for servers and other features, like tracking, etc., is not available for .NET servers. So while GraphQL is server agnostic there was not too much available to get a kickstart for .NET Framework apart from the promise of its being possible.

We finally got started with a combination of these blogs/articles!

With a good understanding of how the system will work we then implemented a couple of APIs for the new system in GraphQL to see how it will fit in with the existing system.

Existing APIs:

For am existing call like GetChildrenInterestedInHobby(int hobbyID), if the current SP returns only childNames and IDs and not the ParentID, then a client call trying to access the Child's parents name won't really return any data anyway, as it has no way to resolve the parent info.

New APIs:

  • The new feature requirement could, as such, be implemented reusing a lot of the existing SPs.
  • In order to use GraphQL for these APIs, however, we could not reuse the existing SPs as GraphQL works best when we resolve one entity at a time rather than an SP which joins data across tables and returns a consolidated object. So this meant we would need to replicate the SPs and mark them for use with GraphQL.
  • Even with the use of DataLoader to optimize the DB calls we would end up with a few more DB hits than the existing approach where we make one call per API to a specific SP.
  • The new feature request was pretty small and while a good candidate to get started with GraphQL it would cause code repetition and maintenance overhead if added with existing APIs.
  • On the client-side, also, the GraphQL code would be intermixed with calling older REST APIs.

Our Suggestion to the Customer

  • While GraphQL is server agnostic and can work with any server implementation including the ability to wrap existing implementations under an endpoint, it is best utilized when the server-DB interaction is per entity level so that each entity can get resolved independently.
  • The existing system is working well and has been optimized heavily from a database point of view. Re-wiring it and re-wiring all clients just to use GraphQL is not advisable at this time.
  • The new feature which plugs into the existing system very closely is too small to add a new framework in the mix, will cause repetition of code functionality and a maintenance overhead.
  • We should look to add GraphQL with the next big subsystem which is being planned which will involve new tables, new SPs and a new set of APIs.

With that we concluded our exercise and the team is looking forward to using GraphQL in a new subsystem that is being visualized! Meanwhile we will work to put up a walkthrough of a sample GraphQL Server on the .NET framework with mutations and the works, and hopefully save a fellow .NET developer some time.

.net, apis, big data, data ingestion, graphql

Published at DZone with permission of Anshulee Asthana , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}