In today’s mobile-first, performance-obsessed landscape, the way we design APIs can make or break the user experience. This goes beyond tech debt or developer convenience, API design directly affects how fast your app feels, how much battery it drains, and whether users stay engaged. While REST has been the default for years, more flexible approaches like GraphQL and batched endpoints are reshaping how we think about data delivery. Let’s deconstruct how thoughtful API design unlocks better UX, particularly for mobile and progressive web apps.
Key Definitions
REST (Representational State Transfer): A traditional API approach where each endpoint represents a resource (e.g., /users, /products) and returns fixed sets of data.
GraphQL: A query language and runtime that lets clients request exactly the data they need, no more, no less, from a single endpoint.
Over-fetching/Under-fetching: Problems common in REST where clients receive too much or too little data, leading to inefficient additional requests.
Batched APIs: Techniques that allow clients to group multiple related requests into one network call, improving efficiency.
Case Study 1 - Spotify (Web API):
Spotify’s public Web API is RESTful by default. When building apps or integrations, developers must hit different endpoints for albums, tracks, and artists. On mobile, this can result in multiple round-trips and increased latency, especially in areas with poor connectivity.
However, Spotify internally leverages more advanced data aggregation strategies. In its native mobile apps, data requests are optimized and likely batched server-side to avoid hitting multiple endpoints. The experience feels fast and seamless because the client gets only what it needs in one shot, mimicking GraphQL-like behavior even within REST.
Case Study 2 - Starbucks PWA:
When Starbucks rebuilt its ordering experience as a Progressive Web App (PWA), performance was critical. To provide near-native performance and reduce data usage, they moved from REST to GraphQL. The change allowed the frontend to query exactly what it needed, such as store info, inventory, and personalization data, in a single, optimized request.
The benefits were immediate: faster load times, smoother UX, and significantly reduced redundant data fetching. This made a huge difference for users in areas with weak connections, aligning with Starbucks’ goal to serve customers globally.
Case Study 3 - Shopify (Storefront API):
Shopify offers a GraphQL-based Storefront API that powers many custom frontends, headless commerce apps, and mobile experiences. One major win is the ability for a product detail page to request all necessary data in one query: product images, prices, availability, variants, reviews, and recommendations.
Previously, this might have required multiple REST calls, each introducing latency and coordination challenges. With GraphQL, developers build data requests around UI needs, not around server data models. This results in more responsive and efficient experiences.
Final Words
APIs are no longer backend plumbing. They are product levers that determine speed, scalability, and satisfaction. As we’ve seen with Spotify, Starbucks, and Shopify, moving beyond REST, whether through GraphQL, batching, or internal aggregation, can unlock major UX and performance wins.
As PMs, we don’t need to write GraphQL schemas or manage resolvers. But we do need to ask the right questions, push for efficient data flows, and measure what matters. In a world where milliseconds matter, smart API design isn’t just a dev decision, it’s a product advantage.
