Querying Strategies for GraphQL Clients

Summary

GraphQL clients can face slower, larger queries and difficult roll-outs as product screens gain features and data. The Orders & Fulfillments teams examined these issues while targeting a sub-one-second mobile page load on a reliable network. Starting with a product-list query that loads 100 products, the post recommends pagination with page-size/index controls and a hasNextPage field, plus performance tripwires to track loading time. It describes @include and @skip directives, runtime query construction, and chained queries for feature flags or parameters, while warning that chained requests add latency. For growing screens, it separates unrelated filters, permissions, and banners into parallel queries, enabling independent scaling, partial rendering, and less redundant pagination work, while cautioning that server load and partial-data state require monitoring and possible refactoring.

Context

As GraphQL clients accumulate more data and features, queries become larger and slower, roll-outs become more difficult, and the Orders & Fulfillments teams needed to reconsider the foundation of a mobile Order screen after two years of growth. The mobile goal was a consistently sub-one-second page load on a reliable network.

Approach / What changed

The post builds querying strategies from a product-list example: paginate the initial 100-product query, add performance tripwires, control new fields with @include and @skip or runtime-built queries, chain queries only when necessary, and split unrelated screen features into parallel queries. It also discusses partial rendering, server-side load monitoring, and refactoring state handling for partial responses.

Takeaways

• Pagination uses page-size and page-index parameters plus hasNextPage, reducing front-end and back-end load when the page size is lower than the original 100 products.
• With @include and @skip, new fields remain at the same naming and level in the query, and a skipped field is returned as null; dynamically building the query avoids that structural constraint.
• Parallel queries can reduce redundant pagination work and support faster or partial screen rendering, but they transfer load to the server and require tripwires and monitoring to prevent overload.

Related reading