Frontend service
The following is an interaction diagram of the pages in the frontend service.
Suggestion
The use of a progressive web framework is strongly recommended to ensure that the frontend and backend elements of the system are decoupled. It can also help with adding support for a variety of viewport dimensions without having to develop code for each ones in a dedicated fashion. The use of a frontend that uses asynchronous HTTP requests to populate the contents of the DOM can also improve the interaction quality with the said service.
Furthermore, the client side code can help restrict the number of requests sent to the backend service by setting a global count of API requests possible from the frontend with respect to time. We can expect reduced load on the infrastructure as a result of the said design from the frontend users while the API requests made from the webhook services for event invocation can remain free from such restrictions due to their scheduled nature.
Pages expected
The following set of pages can be expected for minimal functionality.
Please note that more pages can be implemented as per functions requested.
Landing page
A minimal page with the name and purpose of the service and a clearly visible login button should suffice.
Clicking on the login button should take people to the Fedora Account System landing page for the access.
This is only visible to people who have not yet logged into the service or have not yet signed up for it.
Listing page
A minimal page with a list of existing services associated with the user and a button for adding new services should help.
Clicking on the aforementioned button should lead people to the page for adding new services.
Clicking on the gear icon beside an existing service element should take them to the page where it can be updated.
Clicking on the message icon beside an existing service element should take them to the associated messages page.
Clicking on the log out button from the avatar icon should revoke access and take the users to the landing page.
This is only visible to people who have logged in the service and those who have not will see the landing page.
New service page
A minimal page with the appropriate fields required to create a new service and buttons to save or cancel should help.
Pressing the save button should send those contents to the API service and take users to the listing page.
Pressing the cancel button should not interact with the API service and simply take users to the listing page.
An alert section or modal should be used to inform users of any issues with the form filled or the response received.
Clicking on the log out button from the avatar icon should revoke access and take the users to the landing page.
This is only visible to people who have logged in the service and those who have not will be redirected to the landing page.
Edit service page
A minimal page with the appropriate fields required to edit an existing service and buttons to save or cancel should help.
Pressing the save button should send those contents to the API service and take users to the listing page.
Pressing the cancel button should not interact with the API service and simply take users to the listing page.
An alert section or modal should be used to inform users of any issues with the form filled or the response received.
Clicking on the log out button from the avatar icon should revoke access and take the users to the landing page.
This is only visible to people who have logged in the service and those who have not will be redirected to the landing page.
View messages page
A minimal page with a list of message entries associated with the said service and a back button should help.
Pressing the back button should not interact with the API service and take the users back to the listing page.
Clicking on the message should take them to the Datagrepper page associated with the message signature.
A count of the messages should be available on the header and effective pagination should be implemented.
Clicking on the log out button from the avatar icon should revoke access and take the users to the landing page.
This is only visible to people who have logged in the service and those who have not will be redirected to the landing page.