You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Task based queries have arrived on the server, now we have to support them in the client apps.
Architecture-wise, it is smart to separate get the query for an insight from calculate the result for a query. This is why we should create two views/components: The Insight view and the Query view.
Insight View
The insight view gets an insight ID as a parameter and has access to the API service. The insight view's job is to
retrieve the insight from the API with GET /v2/insights/${insightID}/
generate a query from the insight via the API with GET /v3/insights/${insightID}/query/${startDate}/${endDate}/${testMode}/
pass the generated query and it's displayMode to the Query View
In the UI, the display view should be responsible for displaying the title of the insight, and be a container for the query view.
Query View
A Query View's job is to take a native query, run it on the server, and display its result in an appropriate way (see #84 for more details on displaying query results).
To do that, a Query View will retrieve a task ID for the given query, immediately check if there are old results for the given query, and update when newly calculated results for the query come in. These are the units of work a query view should do:
Retrieve a Task ID
We retrieve and store a task ID for the calculation task for this query. The relevant API endpoint currently triggers a new calculation every time we ask for a task ID, but that shouldn't matter to us. It might switch to just returning the last task ID in the future. Either way, we can use the task ID to display that the query is running, to retrieve an old existing result (if any) and later to retrieve the finished result.
Load a task ID with POSTing the query to /v3/query/calculate-async/.
This will return a dictionary of [String: String] with one key: ["queryTaskID": queryTaskID].
Load Data
As soon as we have a task ID, we can already try and display data. The task ID might have (outdated but still valuable) query result data attached to it that we can retrieve and display while the newer query is still running.
Load the task ID's last successful value with GET /v3/task/${taskID}/lastSuccessfulValue/ (this will return a QueryResultWrapper)
At the same time, we want to periodically check the running task's status. It might be finished after a few milliseconds, it might run a minute or two. We'll have to periodically query it
Update the task status periodically with GET /v3/task/${taskID}/status/
The task status should be updated periodically:
Every 0.5 seconds when the last time it was queried the status was "running"
Every 10 seconds when the last time it was queried the status was "successful"
Never when the last time it was queried the status was "error'
Also, if the task status is successful, we should immediately load the last successful value again.
Reference Implementation
The JavaScript Implementation of this loading feature might give some more orientation.
Task based queries have arrived on the server, now we have to support them in the client apps.
Architecture-wise, it is smart to separate get the query for an insight from calculate the result for a query. This is why we should create two views/components: The Insight view and the Query view.
Insight View
The insight view gets an insight ID as a parameter and has access to the API service. The insight view's job is to
/v2/insights/${insightID}/
/v3/insights/${insightID}/query/${startDate}/${endDate}/${testMode}/
displayMode
to the Query ViewIn the UI, the display view should be responsible for displaying the title of the insight, and be a container for the query view.
Query View
A Query View's job is to take a native query, run it on the server, and display its result in an appropriate way (see #84 for more details on displaying query results).
To do that, a Query View will retrieve a task ID for the given query, immediately check if there are old results for the given query, and update when newly calculated results for the query come in. These are the units of work a query view should do:
Retrieve a Task ID
We retrieve and store a task ID for the calculation task for this query. The relevant API endpoint currently triggers a new calculation every time we ask for a task ID, but that shouldn't matter to us. It might switch to just returning the last task ID in the future. Either way, we can use the task ID to display that the query is running, to retrieve an old existing result (if any) and later to retrieve the finished result.
POST
ing the query to/v3/query/calculate-async/
.This will return a dictionary of
[String: String]
with one key:["queryTaskID": queryTaskID]
.Load Data
As soon as we have a task ID, we can already try and display data. The task ID might have (outdated but still valuable) query result data attached to it that we can retrieve and display while the newer query is still running.
/v3/task/${taskID}/lastSuccessfulValue/
(this will return aQueryResultWrapper
)At the same time, we want to periodically check the running task's status. It might be finished after a few milliseconds, it might run a minute or two. We'll have to periodically query it
/v3/task/${taskID}/status/
The task status should be updated periodically:
Also, if the task status is successful, we should immediately load the last successful value again.
Reference Implementation
The JavaScript Implementation of this loading feature might give some more orientation.
The text was updated successfully, but these errors were encountered: