Skip to content

feat: SingletonPropertyDataFetcher, avoid allocating a PropertyDataFetcher per property per graphql operation #2079

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 11, 2025

Conversation

samuelAndalon
Copy link
Contributor

📝 Description

Inspired by graphql-java/graphql-java#3754.
Currently, graphql-kotlin, through the KotlinDataFetcherFactoryProvider creates a PropertyDataFetcher per source's property.

This instance is created every single time the graphql-java DataFetcherFactory is invoked, which happens to be on runtime per property per graphql-operation.

This PR will introduce a new object class SingletonPropertyDataFetcher which will host its own singleton factory that will always return SingletonPropertyDataFetcher which will store all KProperty.Getter<*>s in a ConcurrentHashMap.

Instead of just replacing the SimpleKotlinDataFetcherFactoryProvider, I am creating a new one, to avoid breaking changes, and to allow users to decide what they want, this switch might come with a cost, we are avoiding object allocations, in favor of a singleton that will possibly hold thousands of KProperty.Getter<*>s.

@tapaderster
Copy link
Member

are we missing documentation?

@samuelAndalon samuelAndalon merged commit 2ad2767 into master Apr 11, 2025
11 checks passed
@samuelAndalon samuelAndalon deleted the feat/singleton-kotlin-property-data-fetcher branch April 11, 2025 16:46
samuelAndalon added a commit that referenced this pull request Apr 11, 2025
…yDataFetcher per property per graphql operation (#2081)

### 📝 Description
cherry-pick #2079

---------

Co-authored-by: Samuel Vazquez <[email protected]>
samuelAndalon added a commit that referenced this pull request Apr 11, 2025
…yDataFetcher per property per graphql operation (#2084)

### 📝 Description
cherry-pick #2079

---------

Co-authored-by: Samuel Vazquez <[email protected]>
samuelAndalon added a commit that referenced this pull request Apr 14, 2025
…tcher per property per graphql operation (#2079)

### 📝 Description

Inspired by graphql-java/graphql-java#3754.
Currently, graphql-kotlin, through the
[KotlinDataFetcherFactoryProvider](https://github.com/ExpediaGroup/graphql-kotlin/blob/master/generator/graphql-kotlin-schema-generator/src/main/kotlin/com/expediagroup/graphql/generator/execution/KotlinDataFetcherFactoryProvider.kt#L62)
creates a
[PropertyDataFetcher](https://github.com/ExpediaGroup/graphql-kotlin/blob/master/generator/graphql-kotlin-schema-generator/src/main/kotlin/com/expediagroup/graphql/generator/execution/PropertyDataFetcher.kt)
per source's property.

This instance is created [every single time
](https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/schema/GraphQLCodeRegistry.java#L100)the
graphql-java
[DataFetcherFactory](https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/schema/DataFetcherFactory.java)
is invoked, which happens to be on runtime per property per
graphql-operation.

This PR will introduce a new object class `SingletonPropertyDataFetcher`
which will host its own singleton factory that will always return
`SingletonPropertyDataFetcher` which will store all
`KProperty.Getter<*>`s in a ConcurrentHashMap.

Instead of just replacing the SimpleKotlinDataFetcherFactoryProvider, I
am creating a new one, to avoid breaking changes, and to allow users to
decide what they want, this switch might come with a cost, we are
avoiding object allocations, in favor of a singleton that will possibly
hold thousands of `KProperty.Getter<*>`s.

---------

Co-authored-by: Samuel Vazquez <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants