Hot Chocolatev13
This is documentation for v13, which is no longer actively maintained.
For up-to-date documentation, see the latest stable version.

Overview

In this section we will look at some ways of how we can improve the performance of our Hot Chocolate GraphQL server.

Startup performance

The first GraphQL request issued against a Hot Chocolate server will most of the time take a little longer than subsequent requests. This is because Hot Chocolate has to build up the GraphQL schema and prepare for the execution of requests.

We can however delegate this task to the startup of the application instead of the first request, by call InitializeOnStartup() on the IRequestExecutorBuilder.

C#
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services
.AddGraphQLServer()
.InitializeOnStartup()
}
}

This will create the schema and warmup the request executor as soon as the app starts. This also brings the added benefit that schema errors are surfaced at app startup and not on the first request.

Persisted queries

The size of individual GraphQL requests can become a major pain point. This is not only true for the transport but also the server, since large requests need to be parsed and validated often. To solve this problem, Hot Chocolate implements persisted queries. With persisted queries, we can store queries on the server in a key-value store. When we want to execute a persisted query, we can send the key under which the query is stored instead of the query itself. This saves precious bandwidth and also improves execution time since the server will validate, parse, and compile persisted queries just once.

Hot Chocolate supports two flavors of persisted queries.

Regular persisted queries

The first approach is to store queries ahead of time (ahead of deployment). This can be done by extracting the queries from our client applications at build time. This will reduce the size of the requests and the bundle size of our application since queries can be removed from the client code at build time and are replaced with query hashes.

Strawberry Shake, Relay, and Apollo client all support this approach.

Learn more about persisted queries

Automatic persisted queries

Automatic persisted queries allow us to store queries dynamically on the server at runtime. With this approach, we can give our applications the same performance benefits as with persisted queries without having to opt in to a more complex build process.

However, we do not get any bundle size improvements for our applications since the queries are still needed at runtime.

Both Strawberry Shake and Apollo client support this approach.

Learn more about automatic persisted queries