We compute the schema and cache it for performance reasons.
Note: we assume that the schemaProvider can return different schemas over time. We also assume
that they change relatively slowly.
Note: we rely on object identity to ensure an efficient set comparison. (This is a reasonably good
approach, because we assume immutable collections. Therefore we know we will never skip re-computing
when we should.
Note: we avoid taking locks to avoid thread contention. We accept this at the cost of potentially
re-computing the schema multiple times upon schema change. Additionally, we do not use any volatile
variables, but instead rely on the JVM's guarantee that object references are atomically written.
A GraphQL Schema Provider implementation.
We compute the schema and cache it for performance reasons.
Note: we assume that the schemaProvider can return different schemas over time. We also assume that they change relatively slowly.
Note: we rely on object identity to ensure an efficient set comparison. (This is a reasonably good approach, because we assume immutable collections. Therefore we know we will never skip re-computing when we should.
Note: we avoid taking locks to avoid thread contention. We accept this at the cost of potentially re-computing the schema multiple times upon schema change. Additionally, we do not use any volatile variables, but instead rely on the JVM's guarantee that object references are atomically written.