I understand the problem space intimately - we have a stitching library we use in Atlassian that does a lot of this and more https://github.com/atlassian-labs/nadel

however I was wondering whether this would be a common enough pattern to warrant having a method on the DFE which would do this in one line?

I dont think this is common enough that a DFE gets turned into a downstream query via DFE methods. However the idea that a certain field (and its sub selection and arguments) needs to be forwarded its not crazy.

We have a currently internal class in graphql-java called graphql.normalized.ExecutableNormalizedField - it is what powers the public API called graphql.schema.DataFetchingFieldSelectionSet

This represents a queried field at runtime - eg a executable field that has been normalised into its runtime parts. Its still internal API because its brand new and a fair bit exploratory in some ways. That said the work in Nadel has show its valuable.

One of the things we do in Nadel is create down stream queries from ExecutableNormalizedField objects. We use graphql.normalized.ExecutableNormalizedOperationToAstCompiler to take a NFE and turn it into an AST Document aka a query and then that can be printed using graphql.language.AstPrinter as a string.

SO I don't have an easy answer for you right now in public API terms. You can get to this ENF tree today via graphql.execution.ExecutionContext#getNormalizedQueryTree but its internal API and hence can change with less consideration than public API.

But I guess what I am saying is that this idea of creating downstream queries from specific fields is not a crazy one and we have some of the code to help with it albeit not in public API yet.