Why We Advised Our Customer Against GraphQL
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.
Join the DZone community and get the full member experience.Join For Free
Hortonworks Sandbox for HDP and HDF is your chance to get started on learning, developing, testing and trying out new features. Each download comes preconfigured with interactive tutorials, sample data and developments from the Apache community.
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 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.
- 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.
We finally got started with a combination of these blogs/articles!
- https://fullstackmark.com/post/17/building-a-graphql-api-with-aspnet-core-2-and-entity-framework-core (This is for .NET Core but good to get started).
- https://github.com/JacekKosciesza/StarWars (Again this is for .NET Core).
- https://graphql-dotnet.github.io/ (GraphQL for .NET repo).
- https://github.com/graphql-dotnet/examples/tree/master/src/AspNetWebApi ( Pretty much the only .NET framework example we got and most useful!).
- We also wanted to use GraphiQL but the available nuget was again for .NET Core so we used the GraphiQL repo directly from https://github.com/graphql/graphiql.
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.
For am existing call like
GetChildrenInterestedInHobby(int hobbyID), if the current SP returns only
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.
- 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.
Published at DZone with permission of Anshulee Asthana , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.