What should we pick, GraphQL or REST for our mobile app?

[Aurora.W]

I'm trying to decide if I should use a single GraphQL endpoint for our new mobile app or stick with the established REST API. The frontend team likes the flexibility of fetching exactly what they need in one call, but I'm worried about the complexity of caching and rate limiting on our end.

[Jeffrey60]

We tried a single GraphQL endpoint for the mobile app. It sounded great for fetching exactly what we need, but caching got hairy fast. We added persisted queries, a gateway level per user rate limit, and a small server side cache for the hot queries. The data transfer dropped by about 30% and the timing became more predictable, but the ops got heavier and we tied a lot of logic to the schema changes.

[Paul15]

From my side, sticking with REST would have simpler caching. HTTP caching, CDNs, and straightforward rate limits felt safer to reason about. The mobile team sometimes complains about overfetch, but we can mitigate by versioned endpoints and small payloads.

[TimothyS]

We did a sprint with a small surface API for the main screens and left the rest as REST. It helped reduce overfetch on some endpoints, but keeping the two systems in sync and the diffs in docs was a constant drain.

[Aurora.J]

Do we actually need one endpoint for everything, or would a hybrid approach with shape specific cache rules work better?