# Costly nested resolvers

**URL:** <https://community.apollographql.com/t/costly-nested-resolvers/6441>\
**Category:** Server\
**Tags:** server\
**Created:** [July 3, 2023, 6:24am UTC](https://community.apollographql.com/t/costly-nested-resolvers/6441 "2023-07-03T06:24:37Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![johache-bunker](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/johache-bunker/32/4408_2.png) [@johache-bunker](https://community.apollographql.com/u/johache-bunker)\
**Post date:** [July 3, 2023, 6:24am UTC](https://community.apollographql.com/t/costly-nested-resolvers/6441/1 "2023-07-03T06:24:37Z")

</div>

Hi all,

I face some performance issues linked to a costly nested resolver.

I have a GQL endpoint that roughly looks as follows

```graphql
type Query {
  foos(): [Foo!]!
}

type Foo {
  id: ID!
  fieldA: string
  fieldB(input: Object): [Int!]! # Uses info from Foo + input to run an SQL query
}

```

```typescript
// simplified resolver
const FooResolvers: Resolvers = {
  Query: {
    foos: async (
      _parent,
      args: QueryFooArgs,
      context: Context,
      info: GraphQLResolveInfo
    ): Promise<GQLFoo[]> => {
      return sql.fetchFoos(); // fieldB === undefined
   }
},
Foo: fieldB: async (
      parent: GQLFoo,
      args: FooFieldBArgs,
      context: Context
    ): Promise<FieldB> => {
      return sql.groupByAndSum(args.input, parent.id);
    },

```

I have a nested resolved for fieldB which works fine.

1. I fetch all `Foo`s in the `foos()` query resolver, and then
2. in the `Foo::fieldB` nested resolver, I use the `Foo` details + `fieldB`’s input to produce `fieldB`. However, it’s a relatively complex aggregation that requires a read on my database.

Given that `foos()` returns an array of Foo, which can grow relatively large, I would rather not do N individual requests to my DB.

For something like `fieldA`, even if it needed some computation, I know that I can access the field list in the top query resolver by using `info.fieldNodes[0]?.selectionSet`. However, it seems slightly more complicated, and way less reliable for `fieldB`, since it has argument in the form of an object.

My questions are:

1. This generally seems like an anti-pattern. Is there a better way to batch my nested resolvers?
2. Is there a proper way to access my nested resolver’s arguments from the top query?

Thanks in advance!

---

<div class="post-metadata">

**Author:** ![Justin\_Gonzalez](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/justin_gonzalez/32/5359_2.png) [@Justin\_Gonzalez](https://community.apollographql.com/u/Justin_Gonzalez)\
**Post date:** [February 6, 2025, 8:48pm UTC](https://community.apollographql.com/t/costly-nested-resolvers/6441/2 "2025-02-06T20:48:41Z")

</div>