feat: Add PerformanceApi to CozyClient #1574

Ldoppea · 2024-12-17T16:03:46Z

We want to be able to measure CozyClient's performances in web apps but also in mobile apps

To make this possible we introduce the PerformancesAPI (full documentation available in the PR)

This API should be injected in CozyClient's constructor, then CozyClient will be able to use it to measure performances

This API is meant to wrap platforms' native APIs. On web browsers we wrap the well known Performance API, but on mobile app we may want to use the implementation from react-native-performances

The CozyClient provides the web implementation, but other implementation should be implemented by consuming apps and then injected in the CozyClient's constructor

If no implementation is injected in the constructor, then the defaultPerformance implementation is used. This implementation does nothing, so there is no impact on web apps by default

Here is the result when using the browser's Performance devtools :

Related link:
https://developer.mozilla.org/en-US/docs/Web/API/Performance

TODO:

Add documentation for the new API
Add link to the Flagship implementation to the Other platforms section of the documentation

We want to be able to measure CozyClient's performances in web apps but also in mobile apps To make this possible we introduce the PerformanceAPI This API should be injected in CozyClient's constructor, then CozyClient will be able to use it to measure performances This API is meant to wrap platforms' native APIs. On web browsers we wrap the well known Performance API, but on mobile app we may want to use the implementation from react-native-performances The CozyClient provides the web implementation, but other implementation should be implemented by consuming apps and then injected in the CozyClient's constructor If no implementation is injected in the constructor, then the `defaultPerformance` implementation is used. This implementation does nothing, so there is no impact on web apps by default Related link: https://developer.mozilla.org/en-US/docs/Web/API/Performance

paultranvan · 2024-12-19T12:11:55Z

Some remarks, but excellent work overall with great documentation 👏

packages/cozy-client/src/store/index.js

paultranvan · 2024-12-19T11:44:42Z

packages/cozy-client/src/store/index.js

+      markName: markName,
+      measureName: `${markName} query or mutate`,
+      category: 'CozyClientStore'
+    })


Here are for actions that are not query nor mutate, so I think the measureName is wrong.

Fixed here

I renamed it ${markName} no query nor mutate action

paultranvan · 2024-12-19T11:52:42Z

packages/cozy-client/src/store/index.js

+    markName: markName,
+    measureName: `${markName} default`,
+    category: 'CozyClientStore'
+  })


I think the correct measureName should be ${markName} queries here

Fixed here

I renamed it ${markName} queries but I'm wondering if this is correct too? Those can be queries or mutation? Does "queries" implies this can be also mutation?

paultranvan · 2024-12-19T11:56:56Z

packages/cozy-client/src/store/queries.js

      const response = action.response
      // Data can be null when we get a 404 not found
      // see Collection.get()
      // but we still need to update the fetchStatus.
      if (!response.data) {
+        performanceApi.measure({
+          markName: markName,
+          measureName: `${markName} with data`,


${markName} with no data

I also renamed the next one (line 209) with object as there was also a ! operator I missed

paultranvan · 2024-12-19T11:58:53Z

packages/cozy-client/src/store/queries.js

+        markName: markName,
+        measureName: `${markName} default`,
+        category: 'CozyClientStore'
+      })


I'm not sure it is really needed to have different measures here, i.e. if there is no data, if there is an array or not, etc.
I think only one measure is enough

On my initial tests, this was to have an idea of the frequency of each return path. Not sure if this is still relevant.

paultranvan · 2024-12-19T12:05:13Z

docs/performances.md

+
+On initial implementation, we chose to measure some parts of the code that we estimated useful and with potential high impact on performances (i.e. queries, store management, pouch management etc.)
+
+We excpect to need more measurements in the future but we need to care to keep the balance beetween having useful measurements and to not visualy overload the measurement graphs


s/excpect/expect

paultranvan · 2024-12-19T12:05:51Z

docs/performances.md

+
+We excpect to need more measurements in the future but we need to care to keep the balance beetween having useful measurements and to not visualy overload the measurement graphs
+
+The API is meant to be simple to use so measurements can be quickly added temporarily in development environements


s/added temporarily/temporarily added

s/environements/environments

paultranvan · 2024-12-19T12:07:24Z

docs/performances.md

+The API interface is described in the JSDoc
+
+Example of custom implementations:
+- Flagship App: [](TODO ADD LINK)


Will we think of this? 😄

For sure, the task is on the PR description's todo list, so I should not forget to do it (I won't merge this without adding the link).

Done: https://github.com/cozy/cozy-client/compare/fabe643260d358b4cd558200d45dec15387e476b..2d7973e259ca4c6eb6e1c134e0dad87875518288

paultranvan · 2024-12-19T12:08:29Z

docs/performances.md

+
+The consuming app is then responsible to inject an implementation or keep the default one that doesn't do any profiling, regarding if the app is built for development environments or for production
+
+PerformancesAPI seems to have an impact on performances light enough to be kept on production. However, we suggest to disable them in that environement if possible


s/environement/environment

light enough to be kept on production

Are we sure of this? I guess it's ok for a single measure, but I would assume a significative impact overall, since there can be a lot of measures during an app data lifecycle

My guess is that, because the API can measure durations as small as a few μs, on high level methods this should not be perceptible. But this may be different on some API for other platforms. Also I did not find any info about it so this is just a guess.

But that's why I suggested to disable it.

paultranvan · 2024-12-19T12:11:20Z

docs/performances.md

@@ -0,0 +1,169 @@
+# Performances analysis


This doc is really great!
One small remark is that you seem to really dislike ending dots at the end of sentences 😆

This is an old habit from one of my first jobs where we avoided adding hard stops at the end of paragraphs on markdown documents.

But I almost have no memories of why this was on guidelines 🙃 (maybe it was something like the rendered that automatically added dot when double \n after a paragraph, but I'm not sure)

I have no opinion on this. I will add them.

My opinion here is to respect grammar as best as we can 😄
But it's true that we took the habit of missing the final dot in general. Dot.

As we encounter some performances issues in the app startup, we want to add some metrics to understand where time is consumed All measurement are made through the `measure.ts` helper that wraps the `react-native-performance` library and fit the incoming CozyClient performance API Related PR: cozy/cozy-client#1574

In cozy/cozy-client#1574 we implemented a new CozyClient API that allow to enable CozyClient's internal performances measurements This PR configure CozyClient and related links with a react-native compatible Performance API This will allow us to analyse performances issues on CozyClient when used in the Flagship App environment

As we encounter some performances issues in the app startup, we want to add some metrics to understand where time is consumed All measurement are made through the `measure.ts` helper that wraps the `react-native-performance` library and fit the incoming CozyClient performance API Related PR: cozy/cozy-client#1574

In cozy/cozy-client#1574 we implemented a new CozyClient API that allow to enable CozyClient's internal performances measurements This PR configure CozyClient and related links with a react-native compatible Performance API This will allow us to analyse performances issues on CozyClient when used in the Flagship App environment

As we encounter some performances issues in the app startup, we want to add some metrics to understand where time is consumed All measurement are made through the `measure.ts` helper that wraps the `react-native-performance` library and fit the incoming CozyClient performance API Related PR: cozy/cozy-client#1574

In cozy/cozy-client#1574 we implemented a new CozyClient API that allow to enable CozyClient's internal performances measurements This PR configure CozyClient and related links with a react-native compatible Performance API This will allow us to analyse performances issues on CozyClient when used in the Flagship App environment

As we encounter some performances issues in the app startup, we want to add some metrics to understand where time is consumed All measurement are made through the `measure.ts` helper that wraps the `react-native-performance` library and fit the incoming CozyClient performance API Related PR: cozy/cozy-client#1574