To support generation of links to share between the internal (administrative) and external (participant) application, we decided to design it as follows.
A similar data model for each type supported, the three types supported are
Team
Task
Multiple tasks
A link table will be created in the database for each type to ensure simplicity both in generating and controlling the process and in relation to fetching and translating the links in the external application.
To ensure that links are not regenerated and stored in the database multiple time we will implement functionality to generate hash codes for each link so it can be compared on regeneration and reused.
The hash code is the key that will be part of the link url ex.
The link will be created in the internal application.
Where the functionality is available we should add a icon / button control to show the link
show eg.
Functionality should be used to build the link where needed and to store the link.
for complex links we could require that the filter / query is saved and that way we will have a reference to point at.
To ensure that we don’t create multiple links for the same item/entity/query we will generate a HashValue and use that as a key.
It will be parsed in the external web and should always show a minimum amount of information on a unprotected route in the external web.
Three routes will be avaliable
for a team
for a single task
for a task query
A details page for each should also be in an unprotected route in the external web.
Require login/protected route when “Register” button on task is clicked in the external web.
or when joining a team
This functionality is referenced a number of places in the specifications.
A single task
A single Team (show multiple tasks)
Complex / filtered task view (show multiple tasks)
be using RabbitMQ https://www.rabbitmq.com/ an open source MIT licensed widely used messaging queue solution that can easily be plugged into the .net core solution.
RabbitMQ is highly scalable.
A queue is file based and will require allocated storage in the solution.
To ensure we do not overload the database with requests when the queues run, we’ve decided the following.
Queuing messages will happen instantaneously in the API container.
Dequeuing messages will happen in a different container
In intervals ex. every 30 seconds and batched together when writing data to the database.
Format of the items names could be something like:
Internal.<cvr>.task
Internal.<cvr>.updateCPR
External.<cvr>.task
Configuration will be in the application settings and will be used in all queues.
They would containDequeue interval in seconds
Retry time in seconds
Number of Retry before giving up.
Queue location root
There will be a basic queue service to use in the API
There will be a queue for each unique type of functionality we need to handle in a separate dequeuing solution in a different container.