Auke Booij 67b922bac1 Avoid GraphQL schema rebuild when changing irrelevant Metadata ... This increases the speed of `create_query_collection` and `add_collection_to_allowlist` by a factor ~~10~~ 65, by caching the in-memory GraphQL schema. This speedup also applies more broadly to Metadata changes relating to: - allowlists - query collections - cron triggers - REST endpoints - API limits - metrics config - GraphQL introspection options - TLS allow lists - OpenTelemetry When is construction of the in-memory GraphQL schema cached between Metadata operations? Before this PR, **never**! It's rebuilt fully, for every role, on every Metadata operation. However, there are many Metadata operations that don't influence the GraphQL schema. So we should be caching its construction. The `Hasura.Incremental` framework allows us to cache such constructions: whenever we have an arrow `Rule m a b`, where `a` is the input to the arrow and `b` the output, we can use the `Inc.cache` combinator to obtain a new arrow which is only re-executed when the input `a` changes in a material way. To test this, `a` needs an `Eq` instance. (Before hasura/graphql-engine-mono#6877, this was a `Cacheable` type class which has now been removed.) We can't simply apply `Inc.cache` to the "Steps 3 and 4" in `buildSchemaCacheRule`, because the inputs (components of `BuildOutputs` such as `SourceCache`) don't have an `Eq` instance. So the changes to `buildSchemaCacheRule` restructure the code so that the input to "Step 1", namely the Metadata, can be used as a caching key instead, so that `Inc.cache` can be applied to the whole sequence of steps. That works to cache construction of the GraphQL schema, but it means that now only those Metadata operations that _don't_ influence any of the products of steps 1-4 can use a cached build of the GraphQL schema. The most important intermediate product is `BuildOutputs`. So now the exercise becomes to minimize the amount of stuff stored in `BuildOutputs`, so that as many Metadata operations as possible can be handled outside of the codepath that produces a GraphQL schema. Per hasura/graphql-engine-mono#6609, the `BuildOutputs` structure is too big, and stores things unnecessarily. Refer to the PR description there for reasoning - the same logic applies to this PR, and simply goes a few steps further. In doing so, it can benefit from hasura/graphql-engine-mono#6765, which allows us to verify at compile time that certain Schema Cache building steps _don't_ generate "Metadata dependencies". If a certain Metadata dependency is never generated, we don't need to handle that case in `deleteMetadataObject`. Thus such intermediate products don't need to be passed through `resolveDependencies`, and thus they don't need to be stored in `BuildOutputs`, and thus their rebuild won't trigger a GraphQL schema rebuild. PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6613 GitOrigin-RevId: 27d2e69d3461bd4c32f08febef9995c0369fab3a		2022-11-23 07:54:01 +00:00
..
Common.hs	Avoid GraphQL schema rebuild when changing irrelevant Metadata	2022-11-23 07:54:01 +00:00
Dependencies.hs	Avoid GraphQL schema rebuild when changing irrelevant Metadata	2022-11-23 07:54:01 +00:00
Fields.hs	Make Schema Cache building code slightly more readable	2022-11-15 20:14:22 +00:00
Permission.hs	server: delete the Cacheable type class in favor of Eq	2022-11-21 16:35:37 +00:00