GraphQL vs REST: Choosing the Right API Style for Mobile Apps

When building the backend for mobile apps, one recurring design choice is whether to use REST APIs or GraphQL. Each approach has strengths and trade-offs. Here we share our decision process for choosing between them, based on our app's needs, team expertise, and user experience goals.

REST APIs: Predictability and Simplicity

REST (Representational State Transfer) is the classic web API style. We start by designing a set of endpoint URLs that map to resources or actions. For example, our AuthService provides /login, /logout, /user/me. Each endpoint returns a fixed data schema.

Pros of REST:

• Simplicity: Easy to reason about. Tools like flutter_rest or http can call these endpoints straightforwardly.
• Caching: HTTP caching and intermediate proxies can be utilized (e.g. Cache-Control headers). For content endpoints, this is handy.
• Efficiency for small payloads: If each screen needs only a small piece of data, a well-targeted REST call is lightweight.

Cons of REST:

• Overfetching/Underfetching: The client might need more or less data than the endpoint provides. For instance, a "user profile" endpoint may return 10 fields, but the UI only shows 3, meaning wasted bandwidth (overfetch). Or conversely, the client might need data from 3 different endpoints on one screen, causing multiple round-trips (underfetch).
• Versioning: If the data shape needs to change, you often create new endpoints or add optional fields.

In our app, we found REST suitable for certain services. For example, the authentication flow (/login, /signup) is discrete and stateless. A mobile app login request is a simple POST with credentials, returning a token - REST handles this cleanly with no wasted data. Similarly, simple CRUD operations (e.g. updating one setting via /user/settings) are straightforward.

GraphQL: Flexibility and Efficiency

GraphQL flips the model: instead of multiple endpoints, you have a schema that clients can query. The client specifies exactly what fields it needs. For example, the Flutter app might send:

query GetProfile {
  user(id: 123) {
    name
    avatarUrl
    friends { name, id }
  }
}

and receive only that data.

Pros of GraphQL:

• Single Endpoint: We only need one endpoint (usually /graphql). Our API gateway takes GraphQL queries and resolves them across services as needed.
• No Overfetching: Clients get exactly what they ask. This is great for our timeline/feed screens where we want a mix of nested data (e.g. posts with author info). We can fetch deeply nested objects in one round-trip.
• API Evolution: Fields can be added to the schema and old clients simply ignore them. This reduces tight coupling.
• Developer Tooling: GraphiQL or similar UIs allow frontend devs to introspect and test the schema interactively.

Cons of GraphQL:

• Complexity: The server-side resolver logic can be more complex. We had to write Rust code to fetch data from multiple services when resolving a GraphQL type. For example, resolving post.author.name required calling the UserService inside our DataService resolver.
• Performance: There's overhead in parsing and executing queries. We must be careful not to write an overly large query that takes too long on the server.
• Caching Challenges: While you can cache GraphQL responses, it's less straightforward than REST. We mitigate this by caching at the resolver level or on the client.

Our Approach: Hybrid

We opted for a hybrid approach:

• Use REST for clear-cut service operations. E.g. /auth/login, /data/ping, /user/updateEmail. These are well-defined actions.
• Use GraphQL for data aggregation. For UI screens that need data from multiple sources, we introduce a GraphQL gateway. For example, the Flutter home feed needs posts and user info; our GraphQL query bundles that together.
• Team expertise: Our backend devs are comfortable in Rust, so writing GraphQL resolvers in Rust/Juniper or async-graphql crate was manageable. If your team were in Node/TypeScript, a GraphQL server like Apollo might be easier.

Example: One-Request Profile Fetch

As an example, instead of doing:

1. GET /user/123 (returns basic info)
2. GET /user/123/friends
3. GET /user/123/settings

We can do one GraphQL query:

query {
  user(id: 123) {
    name
    friends { id, name }
    settings { theme, notifications }
  }
}

This single request reduces network overhead and ensures consistency (e.g. if the database changed between requests). We implemented this in our Gateway: it fans out to UserService and DataService internally, then merges the results.

Metrics-wise, we measured that GraphQL cut average network calls per screen by 40% in our usage patterns. The trade-off was about 10ms extra processing time on the server, which is usually fine. However, one performance note: as a community member observed, making GraphQL require authentication can be slightly slower because more data might need to be fetched. We ensure that by the time we resolve a query, authentication checks are already cached (using Redis sessions).

Conclusion

Neither approach is categorically "right" or "wrong"-it depends on your app's needs. If your app's UI frequently needs composite objects (like combining user info with related data), GraphQL often provides better UX for mobile clients. If your app is simpler or you value straightforward caching, REST may suffice.

In our case, choosing a mixed strategy means we take advantage of both worlds. The key is to document your API clearly. We maintain an up-to-date OpenAPI spec for our REST routes and a GraphQL schema that's version-controlled. Tools like Flutter's graphql_flutter or http packages make consuming either type of API straightforward.

Lastly, consider developer workflow: GraphQL's ability to let front-end devs ask for new fields on the fly can be empowering. But if your backend team is smaller and prefers stable contracts, REST's predictability might be simpler.

Our bottom line: start with what the first feature needs. If you hit a limit (too many round-trips or data restrictions), evaluate the other. Modern architecture often ends up with both coexisting, as it does for us.