# Increased query complexity when using fragment colocation

**URL:** <https://community.apollographql.com/t/increased-query-complexity-when-using-fragment-colocation/8928>\
**Category:** Client SDKs\
**Tags:** client, web\
**Created:** [April 16, 2025, 9:33am UTC](https://community.apollographql.com/t/increased-query-complexity-when-using-fragment-colocation/8928 "2025-04-16T09:33:35Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Omar\_Ayman](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/omar_ayman/32/5992_2.png) [@Omar\_Ayman](https://community.apollographql.com/u/Omar_Ayman)\
**Post date:** [April 16, 2025, 9:33am UTC](https://community.apollographql.com/t/increased-query-complexity-when-using-fragment-colocation/8928/1 "2025-04-16T09:33:35Z")

</div>

if I have a query like

```auto
query Posts {
  posts {
    id
    title
    description
  }
}

```

and extract some fields to a fragment like this

```auto
query Posts {
  posts {
    id
    title
   ... Description
  }
}

fragment Description on Post {
   id
  description
}

```

I have my server setup with a maximum query complexity, so the request fails with the following error

```auto
 maximum query complexity exceeded x > y

```

my question is, is there a way to modify the query at request time to jam in the fragment fields into the main query, so the request query will be back to

```auto
query Posts {
  posts {
    id
    title
    description
  }
}

```

---

<div class="post-metadata">

**Author:** ![lenz](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/lenz/32/4007_2.png) [@lenz](https://community.apollographql.com/u/lenz)\
**Post date:** [April 16, 2025, 9:40am UTC](https://community.apollographql.com/t/increased-query-complexity-when-using-fragment-colocation/8928/2 "2025-04-16T09:40:51Z")

</div>

No, that’s not possible.

Apollo Client has no knowledge about your schema, and it cannot know if `posts` is of the actual type `Post[]` or if it is of e.g. an interface that could contain other array members than `Post` that might be lacking `description` or where `description` is of a different, incompatible type.

Blindly inlining could cause errors both on the server (query doesn’t match schema) and on the client (unexpected types are returned).

As alternative solutions, I would recommend you contact the server team and have a discussion about the query complexity calculation - or you use something like persisted queries that are whitelisted and thus not subject to complexity calculations in the first place.