REST vs GraphQL Technical Discussion

REST vs GraphQL

Quick Definitions

• REST (Representational State Transfer): Like ordering from a fixed menu at a restaurant. Each endpoint serves a specific dish (data structure). You get what’s on the menu, nothing more, nothing less—even if you only want part of it.
• GraphQL: Like ordering à la carte. You specify exactly what you want across all available ingredients (data fields), and get precisely that in one request.

Decision Matrix

When to Choose Each

Choose REST when:

• Building a public API others will consume (standardized, familiar)
• Data access patterns are simple and well-defined
• Caching and CDN usage are critical (HTTP caching is free)
• Team lacks GraphQL expertise (lower learning curve)

Choose GraphQL when:

• Frontend needs vary widely (admin dashboard vs mobile vs widget)
• You’re over-fetching/under-fetching data with REST (making 4+ calls per screen)
• Mobile bandwidth is critical (emerging markets, data-conscious users)
• You have many client types consuming the same backend

Scenario: Mobile News App

Product Problem:
Mobile news app makes 6 REST calls to load the home feed: user profile, articles list, author details, bookmark status, read status, and recommendations. On 3G networks, first paint takes 4.5 seconds. Users in India and Brazil churn at 40%.

PM Decision:
Switch to GraphQL for the mobile app. Single query fetches user + articles + authors + statuses. Keep REST for public article API (partners integrate with it).

Trade-offs:

Real Numbers:

• Time to first paint: 4.5s → 1.2s (73% improvement on 3G)
• Bandwidth per load: 450KB → 180KB (60% reduction)
• Mobile team velocity: +30% (fewer backend dependency tickets)

Scenario: Public Developer API

Product Problem:
You’re launching a payments API like Stripe. Developers will integrate your product into their systems. You need to decide: REST or GraphQL?

PM Decision:
REST. Public APIs benefit from HTTP standards, widespread tooling, and simple documentation. GraphQL’s flexibility isn’t worth the learning curve for external developers.

Trade-offs:

Real Numbers:

• Developer onboarding time: 30 minutes (REST) vs 2 hours (GraphQL for new users)
• Community libraries: 200+ for REST vs 20 for GraphQL
• CDN cache hit rate: 70% (REST) vs 15% (GraphQL, all POST requests)

Interview Response Frameworks

Framework 1: UPBT

“Users need fast app loads, especially on spotty networks. Our mobile app currently makes 8 REST calls to show the ride request screen. This takes 3+ seconds on 3G, causing users to close the app. From a product perspective, GraphQL lets us fetch all 8 data types in one request, reducing load time to under 1 second. This impacts our core metric—time to first ride request. Technically, we’d build a GraphQL layer on top of our existing microservices.”

Framework 2: The Trade-off Sandwich

1. Recommendation: “I’d recommend GraphQL for our mobile app”
2. Pros: “This gives us a 70% reduction in network requests and lets our mobile team iterate without backend changes”
3. Cons: “The trade-off is backend complexity—we need query cost analysis, and caching is harder since GraphQL uses POST requests”
4. Conclusion: “The pros outweigh cons because our mobile team is blocked by backend dependencies weekly, and our emerging market users have bandwidth constraints”

Practice Question

Interview Prompt:
“You’re designing Instagram. Walk me through whether you’d use REST or GraphQL for the mobile app API.”

Key Points to Cover:

• Feed screen requires data from multiple sources (posts, users, likes, comments)
• Mobile users in emerging markets need bandwidth efficiency
• Trade-off: backend complexity vs mobile performance

Model Answer (UPBT):
“Instagram users expect instant feed loads on any network. The feed screen needs posts, author info, like counts, comments preview, and user’s interaction status—that’s 5+ data types per post. With REST, we’d either over-fetch or make multiple requests (slow on 3G). I’d choose GraphQL for mobile. This lets each screen request exactly what it displays. The business metric is time-in-app and load speed. GraphQL reduces bandwidth by 60% and load time from 3s to under 1s. The trade-off is query complexity—we’d mitigate with query depth limits.”

Quick Reference: REST vs GraphQL

30-Second Comparison:
REST = fixed menu (predictable, cacheable, standard). GraphQL = à la carte (flexible, efficient, complex).

Decision Heuristic:

• Public API for partners? → REST (familiar, standard)
• Mobile app with many screens? → GraphQL (one request, less bandwidth)
• Simple CRUD app? → REST (less overhead)
• Dashboard with varied views? → GraphQL (fetch only what you display)

Red Flags (Don’t Say):

• Don’t mention: Apollo vs Relay, specific GraphQL libraries
• Avoid: Resolver implementation, schema stitching details
• Never: “GraphQL is always better” or “REST is outdated”

Power Phrases:

• “The product trade-off is flexibility vs simplicity…”
• “At our expected scale and use case, we’d choose X because…”
• “Users would experience this as faster loads / lower bandwidth usage…”