Mutations over time: Mutations call can be omitted if the list of mutations is static

[taepper]

Sometimes, the includeMutations which are sent by the mutations-over-time component are already known based on user input / selection. In those cases, the {aminoAcid,Nucleotide}Mutations calls are not needed, as they are only used for calculating the includeMutations in case no user selection is given.

These calls take ~3 seconds for the current 200 million reads.

[fhennig]

Okay, I investigated this. The changes need to be made in queryMutationsOverTime.ts. The main bit is that we can get the data we'd get from the endpoint, by simply aggregating the mutations-over-time data:

     const mutationEntries: SubstitutionOrDeletionEntry[] = responseMutations.map((mutation, i) => {
-        const numbers = {
-            count: overallMutationData[i].count,
-            proportion: overallMutationData[i].proportion,
-        };
+        const count = apiResult.data.data[i].map(({ count }) => count ).reduce((acc, c) => acc + c, 0);
+        const coverage = apiResult.data.data[i].map(({ coverage }) => coverage ).reduce((acc, c) => acc + c, 0);
+        const proportion = count / coverage;
         if (mutation.type === 'deletion') {
             return {
                 type: 'deletion',
                 mutation,
-                ...numbers,
+                count,
+                proportion,
             };
         } else {
             return {
                 type: 'substitution',
                 mutation,
-                ...numbers,
+                count,
+                proportion,
             };
         }
     });

And before, where we query the overallMutationData, we only need to get the mutations if we didn't get an explicit list from the user.

But the overallMutationData is also passed back to the component, and then to getFilteredMutationsOverTimeData, where we filter not only by proportion, but also by type. And for that, we need the "parsed" mutation codes, so we know what's a substitution and what's a deletion. That means we'd also have to parse codes ourselves, if we don't do the API call. Or we make a simpler API call to LAPIS just for parsing. (I think we don't currently have a function to parse a mutation code in the frontend).

[fhennig]

Update - We have now implemented pagination for the component, so we don't fetch all the mutations-over-time data for aaaaall the mutations that the user might never look at. However: Because we're now doing the data fetching in two steps, we can't compute the overallMutationData from the over-time data, because that is now fetched per page.

There is no perfect solution now that is as good as what we did before.

Ideas:

• Do n aggregate calls, one for each mutation that we care about. Probably still faster up to a few hundred mutations? But not great to do a few hundred API calls.
• For small n, do the over-time call right away and infer data, so we can still save us the first call.
• Implement a way to pre-select the mutations we care about in the call to the mutations endpoint in LAPIS (i.e. fix it in LAPIS, not here). I've created an issue for this in LAPIS: Allow pre-selecting mutations when calling nucleotideMutations LAPIS#1656

Given the new circumstances, I'm putting this issue back.

Also, since the call is pretty un-parameterized (only by location and date range) it gets cached and is only a problem on first load or whenever you change location/date range (which is maybe not that often).