Topic: Client side caching in android
Speaker: Blaise Tuffet
Today, we are honored to invite Blaise for the talk focuses on client side caching on our android app.
We face the issue that we have numerous services we need to query in order to display 2 main pages:
– Restaurant page : 5 api
– Restaurant search : 2 very slow apis
This is due to legacy apis that are not designed for mobile device and didn’t stand evolution of the business.
In order to mitigate the issue, we decided that it was important to turn to cache mechanism to make relevant data available as fast as possible.
Basic available cache mechanism we survey are as follow :
– no cache/ service level cache (memcache) : speed up the service, but doesn’t resolve latency issue (us->asia roundtrip).
– CDN cache : accelerate significantly abroad services, mostly useful for public/static data
– local cache : same as CDN, can be covered by local db or libraries like volley. First time access is still slow, need to prefetch and refresh in the background.
– db sync: trivial for read only data. more complex for concurrent write situation, either too expensive or conflicts have to be resolved. We want to avoid syncing big db
We focus on improving core experience : restaurant info and restaurant search.
## Restaurant Info
This api requires more data, we don’t want to store it all on the client.
We decided to improve on roundtrips by grouping required data in a single call via service proxy (parse.com) and to enable close cdn to make delivery from us faster. In addition we use simple local cache to enable offline browsing for pre-cached items.
We want to preload some items like favorites, or restaurant with a reservations to avoid having user.
## Restaurant Search
Search api is provided by Solr system with aggregation of multiple data on the server side. Those extra data includes availability information which is not easily cacheable and slow to retrieve and slow down the api drastically.
Ideally we would like to make search instant, while it was taking over 1-5 second per page of 10.
To do so, we decided to extract key data from restaurant info, the one we intent to display:
and the one we want to index for search (and maybe display) :
– food type,
By syncing this index to the device daily, we can have up to date and instant search experience.
We decided not to use Parse.com local cache capability even though we use parse to aggregate our data. We found that parse local cache didn’t meet our expectation in terms of pinning speed and query time.
One critical issue yet to resolve is the restaurant availability for booking. Availability changes rapidly, especially for next few days and for popular restaurants. Moreover it is expensive to compute in our current backend system.
We are experimenting with caching availability for all restaurant at once per day with a CDN expiration of 5 minute for next days and longer for later days. this would leave us with a single api call on search for availability.
# Future step
Make Quota cache more powerful by improving caching logic and server performances. Using CDN cache only is not optimal since once in a while a user will experience a very slow experience, the lesser the amount of user the more will experience the slowdown.
並歡迎訂閱EZTABLE IDEAS! 😀