We have N + 1 problem in our solution. To overcome this problem, we introduce DataLoader. DataLoader adds support for batching and caching in your GraphQL queries.
By default, graphql-dotnet executes queries in parallel. Most of the time that's a desired behaviour. But there is a catch when a parent graph type has dependencies on a child graph type which also uses asynchronous task to resolve field values.
By EF conventions, in a many-to-many relation, you have two standalone entities and a third entity between them which represents a relationship bridge.
You can configure entity relationship following entity framework conventions. Entity framework will auto-create a one-to-many relationship between entities if one of the entity contains a collection property of the second entity. This property is known as a navigation property.
This post focuses more on configuring a persistent data storage rather than discussing different aspects of GraphQL. With that being said, let's connect to an in-memory database for fake testing.
We've come to the point, where you should have a good understanding of GraphQL Queries already. Few things you should keep in mind though, A query should never change the value of a field. In other words, it should always fetch and never modify. Queries are executed in parallel.
At its simplest, GraphQL is about asking for specific fields on objects. Let's extend our simple application to accommodate a complex type.
GraphiQL (pronounced graphical) is an in-browser IDE for exploring GraphQL. I think it's a must-have tool for any server running behind GraphQL. With GraphiQL in place, you can easily give yourself or your team an in-depth insight into your API.
Subscribe to Fiyaz Hasan
Subscribe today and get access to a private newsletter and new content every week!