Should I use GraphQL or two REST calls for user profiles and orders?

[AmeliaYJ]

I’m trying to decide between using a single, more complex GraphQL query or breaking it down into two separate REST calls for fetching user profiles with their recent order history. The single query feels cleaner but I’m worried about over-fetching on the client side if they only need basic profile data sometimes.

[NathanL]

I tried a single complex query once. It looked fast in tests, but on real devices it dragged in profile data plus a big blob of recent orders and we spent days trimming fields just to keep it responsive. With GraphQL the promise was clean, but the cost showed up in over-fetching when people just wanted the basics.

[Lily72]

We went with two REST calls: one for profile, one for orders. Two round trips, yes, but the payloads stayed lean when folks only needed profiles. We could cache the profile data and defer the orders until explicitly opened. It felt slower on first fetch, but the net payload and JS parsing stayed reasonable most days.

[Jeffrey_C]

Maybe the real problem isn’t the data shape, but how the UI uses it. If most screens only show the profile, maybe we should lazy load orders or fetch them only after a user taps. Do we actually need orders on the profile view most of the time?

[Abigail_G]

I once saw a teammate push for a single endpoint, then spent weeks debugging a mismatch when fields migrated. It felt like a memory that never ends. I ended up liking a middle ground: small, well defined endpoints and clear contracts, but I’m not sure what you should do here yet.