Improvements to `Onyx.get`

[kidroca]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Problem:

• Each time a component “connects” to Onyx we read that data from disk before returning it to withOnyx.
• When multiple components ask for the same key at the same time (e.g. during init | switching chats) the key is requested multiple times from storage
• This causes a lot of unnecessary traffic through the native bridge and adds unnecessary CPU / memory usage
• Confirmed with the following manual benchmarks: Improvements for Onyx connect react-native-onyx#63 (comment)

Solution:

This was widely discussed in the following places and it was decided to go with the cache solution:

• Improvements for Onyx: Improvements for Onyx connect react-native-onyx#63
• Benchmark Onyx: Benchmark Onyx react-native-onyx#65
• Latest slack thread: https://expensify.slack.com/archives/C01GTK53T8Q/p1620065578311900

Prevent unnecessary reads from disk

When a request is made to retrieve something from disk capture the task that would resolve with the read data, as more calls for the same key arrive, instead of making a separate call for the same thing redirect the reads to be resolved from the already pending task. This way only one round trip would ever happen for a given key. As soon as the data for the first call is available - all calls are resolved at once.

Cache and lazy loading

As data is read from file, keep a reference/pointer to the data in memory in a cache dictionary
Fill the cache lazily - only after a key was requested and read from file
Remove cache entries after the last connection for the given key is disconnected

---

Additional Work

✔️ Should we implement any benchmarks / metering?

The general principle I like to apply for a benchmark is through method decoration like the same here: Expensify/react-native-onyx#65 (comment)

1. Create a metrics capturing function that tracks call and response information
   • call start/end time
   • call execution time
   • arguments for the call
   • tag returned objects so we can see how much of them are still in memory (Or just tag the cache map since it should pretty much hold the same information - thought this is only possible after the update that adds cache...)
2. Use a ENV variable (let's say ONYX_BENCHMARK) to apply the metring function through decoration to a list of Onyx methods
   • in order to work the methods in the list need to return a promise or have a callback that is triggered when the call is over
   • e.g. the base methods like get, set, merge would pretty much work out of the box
3. Use the same ENV var from above to expose a readCollectMetrics and resetMetrics as an Onyx method
   • you will be able to further aggregate data like: how much calls were there for get with the a specific key
   • this can also include information about how much data is currently in cache, after the update is made

---

Expected Result:

Onyx does not try to retrieve data that is already available in memory

Actual Result:

Onyx will always ask data from AsyncStorage

Action Performed:

N/A

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Affected Platforms:

-[x] Web
-[x] iOS
-[x] Android
-[x] Desktop App
-[x] Mobile Web

Version Number:
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:

View all open jobs on Upwork

[MelvinBot]

Triggered auto assignment to @mallenexpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[marcaaron]

Should we implement any benchmarks / metering?
Benchmarks can help track future degradations/improvements in Onyx

I think the answer to this is that, yes, we should.

Can you briefly include the plan we will be moving forward with here for benchmarking? I think the plan is to create a single job to cover both so if we can add a bit more context in this issue that would be ideal.

I think we should start with the benchmarks in one PR then move to the Onyx improvements. Lmk if that works for you @kidroca .

[mallenexpensify]

Thanks @kidroca, I created the Upwork job, set the price at $2,000, made it private and invited you. Please continue all discussions here, @marcaaron will be assigned for feedback and PR review
https://www.upwork.com/jobs/~016ba245423bf6bb85

[kidroca]

Can you briefly include the plan we will be moving forward with here for benchmarking? I think the plan is to create a single job to cover both so if we can add a bit more context in this issue that would be ideal.

I've included it to the "Additional Work" section. Here is a bit more on that:

Through decoration original source don't have to be modified and the benchmarking logic is maintained separately
In order to achieve this some minor tweaks might be necessary. For example Onyx.get is a private method
Private methods might be moved to separate file (only used internally) so that it can be decorated by the above pattern before it is imported, another approach is to add methods to an object or a class so that they can be swapped on the instance.
This would be easier to explain/discuss on a Draft PR, so I'll open one and we can finalize the idea there

These modifications would allow the user of Onyx to display these metrics however they like

• print a summary on the console
• save/export a json object
• send the data to a remote

One simple example would be:

• if ONYX_BENCHMARK is true
• include a code in E.cash that will
• print/save/export or send collectedMetrics each time when navigation route changes

since ONYX_BENCHMARK is an ENV variable that is available right from build time, when it evaluates to false none of the benchmarking code will be bundled (tree shaking / dead code elimination)

I think we should start with the benchmarks in one PR then move to the Onyx improvements. Lmk if that works for you @kidroca .

Yes, I'll open a draft PR and start with that

[mallenexpensify]

Thanks @kidroca , I hired you in Upwork, I think you still need to accept. Assigning this issue to you now.