GraphQL emerged as a solution for optimizing data retrieval in user interfaces, addressing the inefficiencies of REST and SOAP by allowing clients to request exactly what they need in a single call. While it boasts flexibility and improved client productivity, transitioning to GraphQL requires a new approach and learning curve, especially in .NET environments. Despite its benefits, developers should evaluate its maturity and production readiness before full adoption.

1. GraphQL.net
Tyler Ayers
tyler.ayers@gmail.com

2. REST
client
flow

3. GraphQL
client
flow

4. Why GraphQL?
• REST and SOAP often provide APIs from the server perspective, not optimized for
data and flows from user interfaces
• Apps have to usually make multiple expensive REST calls and do data juggling
to get the data in the for that they need
• Facebook noticed this in their mobile app development around 2012, released
the project as an open source project in 2015
• No over or under-fetching of data, client always gets exactly what they asked
for
• Do everything the client needs in one call, always
• https://www.graphql.org is only a schema definition from Facebook, along with a
reference implementation for nodejs/react
• Open source implementations on GitHub for Python, Go, .NET Core, Scala, etc…

5. GraphQLAPI
Gateway

6. Why GraphQL instead of OData?
• GraphQL is a different approach than OData – OData grew out of the SQL Server
team at Microsoft, basically making the database queryable/editably from web
clients
• It doesn’t however solve the problem of overly complex request flows to get
user interface optimized data
• …and may make the situation worse since you are married to the data model
• Also can offer too much power to clients – they can discover and manipulate
the database and data directly, which is usually not a good idea - only
makes sense in trusted environments
• GraphQL offers more flexibility and simplicity on the client side, probably a
big win for client productivity and speed

7. Why OData instead of GraphQL?
• GraphQL requires a new approach to define and implement GraphQL APIs, with
little built-in support in .NET environments
• Odata has built in support in several key Microsoft technology stacks, could
make it faster to offer internal APIs to clients

8. Why maybe not GraphQL?
• It is a new API format – be prepared to learn a new schema format, basically
replaces Open API definitions with new GraphQL Schemas, and do completely new
implementations for services (very different code than a typical ASP.NET Core
REST API controller)
• .NET GraphQL open source projects are functional, but still relatively young
and maybe not production-ready
• Doesn’t conform to REST principles that built the web – uses POST for
everything

9. How’s GraphQL.net?
• Good! Works great with ASP.net Core, translation from strongly-typed DTOs in
.NET Core to dynamic JSON response payloads works like a charm
• https://graphql-dotnet.github.io/
• ORM / DB integrations lacking, maybe should also be avoided, best if used as an
API gateway which integrates with backend services

10. Demo

11. Who’s publicly using GraphQL?
• GitHub
• Twitter
• The New York Times
• Yelp
• ...
• Your neighbor’s dog?

12. Do some homework..
• Do the intro exercises, they are fast and fun, and do an excellent job of
explaining the intention, platform, and concrete implementation steps
• https://www.howtographql.com/

13. Takeaway:
Always offer an API Gateway to clients – either
GraphQL, REST, or both. Don’t make clients
integrate directly with backend services or
databases.