Tested with production mode and development mode, and in both cases the memory appeared to be going up
in five, which is not a good sign.
Left it running for 30 minutes whilst I collected the memory heap for analysis in the browser.
33.9% of the memory was in client.onmessage. That's the part of GraphQL Apollo client that receives
the messages from the server. 22.14% of the total is in Vuex SET for the GScan workflows data
(it appears under client.onmessage due to the tree call, as SET is called after the data is received
from Apollo Client, but that's 22.14% of the total, not of client.onmessage, see image below).
Deltas take 7.08%.
The majority of the memory used was in flushCallbacks, which is rsponsible for updating components,
creating functional components to react to data changes (e.g. Task and Job components).
