A few diff options to explore. Some things we do know is that we want to limit the cache to only work for samples query (not cohorts, etc).
Also want to be able to trigger cache refresh when updates are received for samples or new samples are persisted to db.
One idea might be to allow dashboard to sub to updates topic and queue cache refresh at that time. i.e., event-driven caching..
Can the apollo client built-in polling trigger something like this? Something to explore..
Notes from standup discussion on 8/7:
Create a separate GraphQL datasource for Samples data
We'll manage samples query through this datasource for a clean separation
In this datasource, we'll fetch, process (e.g. resolve, flatten, etc.), and store all samples in a cache object
This cache will be refreshed (1) every X amount of time and (2) when there are sample data changes in the database. #2 will require subscribing the GraphQL server to the appropriate topics
Requests from the frontend for samples data will be queried directly against the cache instead of to the Neo4j database
The dashboard frontend UX will remain the same (only gets back max 500 rows, etc.)
Related to #1221
A few diff options to explore. Some things we do know is that we want to limit the cache to only work for samples query (not cohorts, etc).
Also want to be able to trigger cache refresh when updates are received for samples or new samples are persisted to db.
One idea might be to allow dashboard to sub to updates topic and queue cache refresh at that time. i.e., event-driven caching..
Can the apollo client built-in polling trigger something like this? Something to explore..
Notes from standup discussion on 8/7: