Update the webapp to fetch and upate tasks in sequence #19
Conversation
…e Task Backend, Adding explanatory comments, using a task queue in the client side
…stead of relative
| * Returns a new task created from the Task Backend. We do a few things here: | ||
| * | ||
| * 1) Get the task from the backend and register the requesting user. | ||
| * 2) Store the task in our local database. |
There was a problem hiding this comment.
probably already clear: When the frontend posts user-information with the fetch-new-task-request the created work_package in the DB will be associated with the user and the backend will accept replies only from the same user (like DM conversation on discord). When no user information was included the task is considered to be 'public' (as in a public channel on discord) and multiple users can reply.
For interactions it is mandatory to send user information (replies and ratings/rankings are always associated with a user).
| user: { | ||
| id: session.user.id, | ||
| display_name: session.user.name, | ||
| auth_method: "local", |
There was a problem hiding this comment.
Currently it would be possible to send the discord user_id as id + auth_method: "discord". We have to discuss the best way to support different auth-providers and still match users. For first v1 we should focus on discord (e.g. same identity used for bot and web).
|
|
||
| // Send the interaction to the Task Backend. This automatically fetches the | ||
| // next task in the sequence (or the done task). | ||
| const interactionRes = await fetch( |
There was a problem hiding this comment.
I would recommend to move all the backend api fetch-impls to a class in a separate file.
somthing like:
export class BackendApi {
public static async sendInteraction(interaction: TaskInteraction, session: Session): Promise<ResponseType> { .. }
}
(use suitable types & names as you like)
This shows an end to end example of how to handle one task type (ratings) with a task queue in the client side and storing all the task & interaction state with an intermediate database. This is mostly to get a working example of a full flow.
In a future PR we will: