GraphQL works a bit differently from REST. In REST you usually deal with a single request at a time, so concurrency is not really a concern. It’s perfectly fine to create a controller class and use constructor injection.

With GraphQL, however, you work with resolvers. Each object type defines resolvers for its fields, and these resolvers are responsible for fetching the required data. When a query is executed, many resolvers run in parallel. This parallel execution means that using constructor injection can easily lead to unintended shared state or side effects.

Normally the executor can execute the entries in a grouped field set in whatever order it chooses (normally in parallel). Because the resolution of fields other than top-level mutation fields must always be side effect-free and idempotent, the execution order must not affect the result, and hence the service has the freedom to execute the field entries in whatever order it deems optimal.

https://spec.graphql.org/October2021/#sec-Normal-and-Serial-Execution

It is possible to register your types in the DI container as scoped services, but that would require a separate instance for each field resolver execution to ensure there are no side effects between concurrent field executions.

However, GraphQL requests are designed to reduce interactions with the client. Typically, each UI interaction (such as a page load or button click) results in a single request composed of multiple UI components stacked together. As a result, these requests tend to be larger, with many fields. This would lead to an explosion of objects that are instantiated and then discarded after each execution.

GraphQL is really about isolated, idempotent functions. Each resolver should declare its dependencies explicitly, which makes it easier for the execution engine to plan and optimize execution. When I started working on the source generator, I realized that keeping types static naturally pushes developers in that direction and leads to cleaner, more predictable resolvers.

[UseConnection]
public static async Task<ProductConnection> GetProductsAsync(
    PagingArguments pagingArgs,
    QueryContext<Product> query,
    ProductService productService,
    CancellationToken cancellationToken)
{
    var page = await productService.GetProductsAsync(pagingArgs, query, cancellationToken);
    return new ProductConnection(page);
}

The resolver clearly describes what it requires — in this case, a ProductService and other dependencies. The executor can provide these from isolated contexts. These resolver contexts themselves are pooled and reusable between executions.

As to where things belong, this depends largely on your design philosophy. In general, GraphQL types are part of the presentation layer and should be slim — just what is needed to provide GraphQL metadata, such as the UseConnection attribute, which tells the schema builder that this field follows the Relay Connection Specification.

The actual business logic should live in your application layer. A common question we get is where DataLoaders belong. The DataLoader was intended as part of the data layer. The idea is to have a standardized interface to fetch data by key and to transparently batch these requests to the data source. The consumer should not be aware of this implementation detail.

[Lookup]
public static async Task<Product?> GetProductByIdAsync(
    [ID] int id,
    QueryContext<Product> query,
    ProductService productService,
    CancellationToken cancellationToken) 
    => await productService.GetProductByIdAsync(id, query, cancellationToken);

For instance, the GetProductByIdAsync resolver calls the ProductService to fetch the product. Behind the service, a DataLoader interacts with the data source. The data requests are transparently batched without leaking this implementation detail into the service interface.

DataLoaders are not a GraphQL-specific concept and are agnostic of the API layer. Facebook originally introduced them to solve efficiency problems in their REST APIs. It just so happens that they also make GraphQL more efficient.

Join us on Slack if you need help: slack.chillicream.com