Skip to content

Commit

Permalink
Fix trailing whitespaces
Browse files Browse the repository at this point in the history
  • Loading branch information
GuusjeJuijn committed Jun 4, 2024
1 parent 24eaa2f commit c22f002
Showing 1 changed file with 8 additions and 12 deletions.
20 changes: 8 additions & 12 deletions docs/architecture/architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -127,20 +127,20 @@ UpdateRelStyle(Tasks, InstrumentRegister, $offsetY="10", $offsetX="-150")
```

### Walkthrough
Suppose a user wants to perform a specific task from the Algoritmekader. To execute this task, the user has 2 options.
Suppose a user wants to perform a specific task from the Algoritmekader. To execute this task, the user has 2 options.

The first option is to execute the task locally by using the command line interface tool (CLI). The CLI tool imports the task from a Python library named `Tasks`. This library contains executable tasks that implement the measures and instruments from the `Instrument Register` (which are specified in the Algoritmekader). Instructions on how to perform these tasks are imported from the Instrument Register. There exists a one-to-one correspondence between measures and instruments in the `Instrument Register` and the task's within the `Tasks` library.
The first option is to execute the task locally by using the command line interface tool (CLI). The CLI tool imports the task from a Python library named `Tasks`. This library contains executable tasks that implement the measures and instruments from the `Instrument Register` (which are specified in the Algoritmekader). Instructions on how to perform these tasks are imported from the Instrument Register. There exists a one-to-one correspondence between measures and instruments in the `Instrument Register` and the task's within the `Tasks` library.

The second option is to use the Algorithm Management Toolkit (AMT). The user starts by visiting the Algorithm Management Toolkit website. Here, the user encounters a front end interface showing a planning board for projects and tasks. This planning board contains 3 columns: ‘To do’, ‘Doing’ and ‘Done’. When a user drags a task from ’To do’ to ‘Doing’, the front end makes an API call to the back end of the AMT.
The second option is to use the Algorithm Management Toolkit (AMT). The user starts by visiting the Algorithm Management Toolkit website. Here, the user encounters a front end interface showing a planning board for projects and tasks. This planning board contains 3 columns: ‘To do’, ‘Doing’ and ‘Done’. When a user drags a task from ’To do’ to ‘Doing’, the front end makes an API call to the back end of the AMT.

The back end consists of three components, showed in the component diagram at the end of this page.
1. An API application, which provides the project and tasks management functionality via HTTPS
The back end consists of three components, showed in the component diagram at the end of this page.
1. An API application, which provides the project and tasks management functionality via HTTPS
2. The business logic, which is the core logic of the AMT
3. A system state, which provides the state of the AMT.
3. A system state, which provides the state of the AMT.

When receiving an API call, the API application forwards the instruction to the business logic. The business logic, in turn, updates the system state and submits the task to the Redis message queue. The message queue stores the task messages until a Celery worker is ready to process a specific task. When a Celery worker is available, it uses the task library to execute the task. After the task is completed by the worker, the result is sent back to the business logic via the message queue. The business logic now sends an update to the system state and writes the result to the database. Finally, the business logic writes a System Card to an external repository.
When receiving an API call, the API application forwards the instruction to the business logic. The business logic, in turn, updates the system state and submits the task to the Redis message queue. The message queue stores the task messages until a Celery worker is ready to process a specific task. When a Celery worker is available, it uses the task library to execute the task. After the task is completed by the worker, the result is sent back to the business logic via the message queue. The business logic now sends an update to the system state and writes the result to the database. Finally, the business logic writes a System Card to an external repository.

Meanwhile, the API application sends regular heartbeats to the system state to check for updates. The system state receives updates from the business logic and checks for updates by reading from the database. When a state is updated (for example, a task is "done" or "failed with error X"), the business logic returns this to the API application. Using a websocket, the API application sends live updates back to the front end, to make sure the planning board stays up to date.
Meanwhile, the API application sends regular heartbeats to the system state to check for updates. The system state receives updates from the business logic and checks for updates by reading from the database. When a state is updated (for example, a task is "done" or "failed with error X"), the business logic returns this to the API application. Using a websocket, the API application sends live updates back to the front end, to make sure the planning board stays up to date.

## Component diagram of the back end of the Algorithm Management Toolkit
Below is a component diagram of the back end of the Algorithm Management Toolkit, with some additional remarks about its components.
Expand All @@ -166,8 +166,4 @@ Rel(API, State, "Sends heartbeat", "HTTPS")
UpdateRelStyle(API, State, $offsetY="-10", $offsetX="-100")
UpdateLayoutConfig($c4ShapeInRow="2", $c4BoundaryInRow="3")
```

0 comments on commit c22f002

Please sign in to comment.