FieldResolver performance
I have made few load tests using same logic with and without fields with FieldResolver query with FieldResolver has 2x worse performance than without them field resolvers I used are very simple ones
Any ideas why? How to improve?
query without field resolvers
query CoinTypes($page: Float!, $pageSize: Float!, $locale: SupportedLocales!) { coinTypes( page: $page pageSize: $pageSize, locale: $locale) { data { id idX defaultCoin { id image { id url __typename } __typename } __typename } total __typename } }
query with field resolvers
query CoinTypes($page: Float!, $pageSize: Float!, $locale: SupportedLocales!) { coinTypes( page: $page pageSize: $pageSize, locale: $locale) { data { id idX ruler { id name(locale: $locale) __typename } mint { id name(locale: $locale) __typename } metal { id name(locale: $locale) __typename } denomination { id name(locale: $locale) __typename } state { id name(locale: $locale) __typename } defaultCoin { id image { id url __typename } __typename } __typename } total __typename } }
@FieldResolver(() => GraphQLString, { name: 'name', nullable: true })
async name(
@Root() someEntity: SomeEntity,
@Arg('locale', () => SupportedLocales) locale: SupportedLocales
): Promise<string> {
return someEntity[`name${capitalize(locale)}`];
}
results with field resolvers (4 of them)
results without field resolvers
Depending on the scale a few more fields could result in a lot more function calls in the resolvers. That coupled with Node.js / JS single threaded nature might be problematic.
My apologies, but I am not seeing the exact lines in the numbers above where the 2x worse performance is demonstrated. That certainly does seem excessive. I am not sure if it is something that we can help with, but if you are able to set up a minimal reproduction using just vanilla graphql JS, that might help.
Closing for now, please feel free to reopen!