Should I split a complex GraphQL query into multiple simpler ones?

[Jeffrey_C]

I’m trying to decide between using a single, complex GraphQL query or breaking it down into multiple simpler ones for our product detail page. The single query feels efficient but it’s becoming a pain to manage the resolver logic and I’m worried about over-fetching on mobile.

[Riley38]

We did something similar. The big query looked great on the whiteboard, but the resolver graph became a maintenance nightmare. On mobile, even when you asked for a few fields you pulled in extras because the schema stitched across types. We ended up breaking the page into small, purpose driven queries and building a tiny client side composer that asks for the pieces the page needs, then renders them.

[LoganSP]

From my side, I leaned toward multiple simpler queries. It felt slower at first, but you fetch exactly what the user sees and it paves the way for field level caching. We watched the mobile payload shrink and the number of fields pulled drop, which was a win for the data plan.

[Jerry16]

Could it be the real problem isn't how you fetch data but how the client renders it? I kept assuming the query shape was the blocker, then found the render path added a lot of cost from images and heavy components. Might be worth profiling both.

[Ella18]

We tried a single complex query but added a thin orchestration layer on the client to request the pieces and hydrate a small view model. It reduced some duplication but the extra round trips and cache invalidation started to bite. Not conclusive, just what I saw in practice.