Our current GraphQL implementation relies heavily on using DataFetchingFieldSelectionSet (based on this guidance). Our service architecture has a GraphQL gateway with multiple micro-services that we call out. These micro-service APIs support selection of properties when fetching data, e.g. /user?$select=(displayName,birthDate). Our resolver implementations will use DataFetchingFieldSelectionSet to map the incoming client query fields to these properties.

Unfortunately the current implementation of DataFetchingFieldSelectionSet set is reconstructed (the entire subtree) for each field resolver, and again each time a child is traversed using the data fetching selection set (using getImmediateFields()[0].getSelectionSet(), ...).

Fortunately the ExecutableNormalizedOperation which is memoized for each request, however when DataFetchingFieldSelectionSet is built it uses this object and in addition traverses the entire sub-tree to build up the glob-patterns, however our use-case is mostly restricted to the immediate children fields, which means we occur the cost of traversing the each field-subtree each time a field resolver requests the selection set.

I have an associated PR that addresses this by making the computation of immediate fields limited, and only if the other methods are used is the entire sub-tree glob-patterns calculated. Opening this to track/discuss the feature/performance/behavior change.