What are the tradeoffs of REST vs GraphQL for nested data queries?

[Kyle_L]

I'm trying to decide between using a RESTful design or switching to GraphQL for our main service endpoints, and I'm stuck on how to handle complex, nested data queries for our frontend without creating a dozen separate calls. The REST approach feels cleaner for our basic CRUD operations, but I keep running into situations where the client needs a very specific set of joined data that would require multiple round trips.

[Nora_G]

We started with REST for the basics. Then the frontend kept asking for a handful of joined bits like user, orders, items, and shipping. We added a BFF service that does the joins and exposes a single endpoint to the UI. It cut down on the number of calls, but it added maintenance and made the data layer feel a bit duct-taped when the schema changed.

[Tyler78]

We did try GraphQL to fix the nested-query pain. It did cut down on back-and-forth, but we had to lock down query complexity and wire in a batching layer so the data sources don’t explode. It sounds good on slides, but in practice it meant another layer of governance and a steeper learning curve for the team.

[Edward_P]

I still wonder if the problem is really the transport. Sometimes we can ship a single REST endpoint that returns a whole screen worth of data and it feels like magic for the UI, other times it just shifts the pain. Caching the screen payload helped a bit, but not every page.

[AdamCH]

Would a hybrid approach help you keep REST for simple CRUD and add a dedicated aggregated endpoint or BFF for the nested needs?