How Apollo Android Client Cache Works at Vrbo
Article Summary
Vrbo eliminated loading screens in their Android app entirely. Here's how they used Apollo GraphQL's normalized cache to make navigation feel instant.
The Vrbo team at Expedia Group rethought their mobile architecture by combining GraphQL orchestration with Apollo's normalized cache. Instead of making multiple network calls as users navigate, they fetch once and slice the cached data as needed.
Key Takeaways
- Replaced multiple network requests with one orchestrated GraphQL call
- Normalized cache stores each type separately with references like a SQL database
- Master detail flows now load instantly from cache with zero loading states
- Custom CacheKeyResolver creates stable identifiers for every response object
- Cross references queries by remapping roots to point at same cached records
By orchestrating backend calls in their data center and leveraging normalized caching, Vrbo turned multi second waits into instant screen transitions.
About This Article
Vrbo's Android app couldn't pass GraphQL objects via Intent between UI components. Developers had to rebuild data structures manually, which created tight coupling between screens during master-detail navigation flows.
Nikola Dobrijevic's team used Apollo's CacheKeyResolver with fromFieldArguments() and fromFieldRecordSet() methods to generate stable cache keys. This enabled the Observer pattern to decouple UI layers from the data layer through live queries.
The normalized cache structure eliminated loading states during navigation. Different queries with different roots could now cross-reference the same cached records, turning multi-second waits into instant screen transitions without extra network requests.