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 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
How we evaluated
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 server 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!
- 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
Existing APIs:-
- Since the existing WebAPIs interacted with the DB on an SP level and returned models specific to the response of the SPs instead of entire objects, the usual graphql magic of client deciding what data it wants to see won’t really work. Take the following simple mock example :-
For a 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 Child’s parents name won’t really return any data anyway as it has no way to resolve the parent info.
- Existing clients will need to be re-wired to use GraphQL
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 .NET framework with mutations and the works . Hopefully save a fellow .NET developer some time 
Team Cennest