feat: open FunctionDataFetcher methods for extension

[smyrick]

📝 Description

Open the internal methods to the protected scope so that we can more easily override specific methods to provide more features. Internally to Expedia Group we have the need to provide a CustomFunctionDataFetcher that overrides the get method. However we don't want to have to reimplement all the other methods as well that convert the classes and parse the arguments. Right now we are actually missing out on using the new feature to use List over array for input types. This could be fixed internally but it is already done in open source so we would like to take advantage of that.

Also this will now allow users to override the coroutine context that is used for suspending functions without having to create an entirely new data fetcher implementation.

For context I found this more helpful for our upgrade to graphql-kotlin 2.0.0-RC4.3

[dariuszkuc]

FunctionDataFetcher is an implementation of DataFetcher interface which only exposes single fun get(environment: DataFetchingEnvironment): Any? function. If one were to extend the FunctionDataFetcher there is no guarantee that any of those methods will be called as one could potentially just override get method again therefore I don't think this is a good idea (also unsure why FunctionDataFetcher is an open class anyway).

Maybe those functions should be made extensions functions (i.e. Java static methods) on the DataFetcher instead?

[smyrick]

@dariuszkuc This came up because in our CustomFunctionDataFetcher we override get with our own implementation because we need to get data from the context to set the thread execution for our tracing data using Haystack.

Is there a better way we can run this custom code but still reuse the other parts in graphql-kotlin around parsing parameter values? Currently we don't have access to get the simple graphql name of a param by checking the annotation and we would also have to implement the logic to get the proper class info

See the logic in convertParameterValue

[dariuszkuc]

@smyrick "proper way" would be to rewrite query execution logic in Kotlin native way and eliminate the dependency on CompletableFuture. Currently we are switching from reactor->coroutine->completable future->coroutine which breaks structured concurrency and requires those workarounds.

That being said for the time being, even though it is not ideal I'm fine with this workaround.