Should I use a single GraphQL endpoint or multiple REST endpoints for mobile?

[RileyG]

I’m trying to decide between using a single GraphQL endpoint or maintaining separate REST endpoints for our new mobile app backend. The flexibility sounds great, but I’m worried about the complexity of caching and rate limiting on a single entry point.

[Brian67]

We tried GraphQL for a mobile backend. The single entry point sounds neat, but caching quickly becomes a mess. We added persisted queries and a gateway cache, tried to cap query depth, and still had to design our own cost budgets and fallback paths. It ended up being more maintenance than REST.

[Madison_B]

We stuck with REST endpoints. HTTP caching with ETag and a CDN kept things fast, and rate limiting was straightforward per endpoint. The client code stayed simple, and you could reason about cache hits by URL. The downside is more endpoints to maintain and some data duplication.

[Lily.H]

I keep thinking the real issue might be offline support or how the app handles data syncing. Sometimes we felt the network was the bottleneck, not the endpoint design. Data shaping mattered more than the protocol.

[Isabella_H]

Have you considered starting with REST and adding a gateway later to test caching and rate limits in a controlled way?