Delivering Instant Update Patches for React Native at Scale

One of the chief reasons why we adopted React Native at Flipkart was to deliver Over The Air (OTA) updates to our 50+ million users instantly. When we looked at the known existing solutions, we found three major issues that were not solved but were critical for us:

1. The updates were not really instant as a cached bundle gets loaded while it silently gets updated in the background.

2. These updates were enormous in size (around 700kB) as the entire bundle gets downloaded at the client-end everytime an update is shipped. For our low bandwith who visit the app once a month, it would take more than 30s for the React Native bundle to get downloaded and the page to be loaded everytime the App is launched.

3. We have multiple teams maintaining their own React Native bundles. When these teams themselves share a lot of common components besides the React Native Framework Code, lots of redundant download is caused.

We built our own system which efficiently solved all of these issues and is being used by multiple Apps inside Flipkart.

This talk discussed the workings of the World's First Differential Download System at Scale that was built at Flipkart.

Transcript

1. Delivering Instant Update Patches for React Native 1 Surya Kanoria @suryakanoria surya.kanoria@flipkart.com
2. Issues with existing OTA solutions • Enormous updates • No way of sharing code across bundles • These issues prevent the app updates from being instant
3. Dynamic Update Service (DUS)
4. Backend Service • A scalable REST service (supporting the basic CRUD operations) • The REST service had the following simple features: ◦ Simple key-value pair storage ◦ Support for multiple keys • Good to have: ◦ Querying based on parameters like App Versions
5. React Native Packager
6. Making bundle generation predictable • During packaging all the Module Ids are obfuscated in a random way • Obfuscate variable names by replacing the random id with a hash of file-path
7. Generating the update patch • Iterate over the bundle splitting each line into a chunk • Generate a hash of the text, making the hash the key and the minified code as the value of the key value pair. • Upload the hashes and the values to the Backend Service.
8. Structure of the update patch { { "productList": ["3eac3e3cd4a15d975da44b29edf365e2be8f664a", "67db44d282dd557a18ab3a56c0303a94a6f893ac", "47b6949479766c7a110fbce6b11ee1b935f449bf"... "c7847a9ebf8bf63e96d85bdff191a995f075706a"], }, { “productDescription”: ["9a68a76836c657db01706caaf19884f8141596f5", "167947aaffa5f2462e4f403e2bcedc886b29bd50", "1944de6302798af223cb745fae75ba9d285f1cc9", "3e8916e703897a848eefb540fd598a399c831344"..."c7847a9ebf8bf63e96d85bdff191a995f075706a"] } }
9. Applying the update patch
10. Sharing code across bundles • Each file is a chunk. Therefore, all common files map into common chunks • Since, the key of each chunk is the hash of the code itself, all common chunks have same keys. • All common chunks are downloaded only once. { "productList": [ "hash1", "hash2, "hash3", "hash4", "hash5 ], "productDescription": [ "hash1", "hash6", "hash3", "hash4" ] }
11. More optimisations... • Gzip your API responses • Maintain versions of update graphs at the REST Service. ◦ Return http code 204 if the client update graph version matches the latest update graph version. • Decrease the size of update graphs by mapping the larger keys to smaller keys • Ship the key value storage with the APK/IPA containing the chunks
12. Summary
13. New features on the fly!!
14. Fewer bytes over the wire... • DUS brought down the size of our updates by 95% from 700KB to ~40KB. • Avoided redundant download of more than 500KB of common code per bundle in production, reducing the download size from 2.8MB to 1300KB.
15. Thank You @suryakanoria