Optimisation of UOP API queries (not used)

[ACLay]

This issue has been replaced by one in ISISBusApps. See https://github.com/isisbusapps/ISISBusApps/issues/1023.

What is the problem and why is it a problem

During yesterday's ISIS direct call the UOP's responsiveness fell to a crawl under the load. To improve performance, one area we've identified that should easily give performance gains is reducing the quantity of data we fetch from the API.

This falls into two main categories:

Reducing the number of API calls made

Pages seem to load data that they don't need, or have already requested. For instance, when I connect to the main landing page as a user, the following graphql requests are made:

• getSettings
• getFeatures
• getUserProposals
• getPageContent - HOMEPAGE
• getCalls
• getPageContent - PRIVACYPAGE
• getPageContent - HELPPAGE
• getPageContent - FOOTERCONTENT
• getCalls

While some of these are understandable and necessary to render the page, others are not. The home page shouldn't need to load the contents of the privacy and help pages. The main dynamic content of a user's homepage is a list of their proposals, so there shouldn't be any need to make multiple requests to getCalls, and one of those is only ever used to pre-populate the "New Proposal"/"Select a call" page, which a user may not even want to visit.

Reducing the quantity of data requested in each API call

To take from the above example, one of those getCalls requests is used to pre-populate the "Select a call" page where a user would go to create a new proposal. The fields used in that page are: id, shortCode, endCall, endCallInternal, title, templateId, description, cycleComment, but the getCalls request includes every single access panel, instrument, and instrument scientist attached to every open call. Especially when that getCalls request is combined with our slow external users service, that's a lot of unnecessary load when multiplied across every page load and user.

For that case it seems like the queries used in the frontend have just been added to and added to so that they can be re-used everywhere that needs a particular type of data, rather than adding new small and specific queries that graphql enables us to make.

Areas identified to improve

• We're requesting too much data to populate the "select a call" page perf: reduce data quantity from high use getCalls query user-office-core#823
• We're making unnecessary requests on the user home page #1196
• Copying generic templates is unoptimised #1193
• Over fetching Data on Fap table #1098
• Optimise STFC user loading and cacheing #1197
• Over fetching of instrument data #1223
• https://github.com/isisbusapps/ISISBusApps/issues/1006
• Optimise PDF generation calls, especially for multiple PDFs #1237
• answerTopic Mutation returns all the answers we just entered, including blank answers for unused questions #1243
• getGenericTemplatesWithQuestionaryStatus query could be made more minimal in GenericTemplatesAnswerRenderer and maybe other places #1244
• getProposal overfetching in ProposalTable #1245
• getGenericTemplate could be made more minimal in places #1257
• getCall Could be made more minimal in ProposalSummary.tsx and ProposalCreate.tsx #1246
• getCallByQuestionId is very slow and is overfecthing data #1247
• getProposalWorkflows should be optimised in ProposalSummary.tsx #1256
• deleteGenericTemplate had a failure rate of 60% and returns details of deleted template when it does not need too #1258
• getGenericTemplatesWithProposalData has a 77% error rate on call deadline #1259
• getMyInstruments over fectching of user data in places #1255
• getCallsByInstrumentScientist over fectching of user data in places #1250
• Improve Xpress performance #1239
• Proposal templates link to proposals tries to load all proposals #1252

Interesting tech that may help

• Looks at Apollo Client as a central state manager #1220