arc/docs/webhook2fedmsg/frsv.rst
Akashdeep Dhar b4694dbf48 Add documentation details on the frontend service
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
2024-04-03 13:54:55 +05:30

108 lines
4.8 KiB
ReStructuredText

.. _frsv:
Frontend service
================
The following is an interaction diagram of the pages in the frontend service.
.. image:: ../_static/w2fm_frsv.svg
:target: ../_images/w2fm_frsv.svg
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. A minimal page with the name and purpose of the service and a clearly
visible login button should suffice.
b. Clicking on the login button should take people to the Fedora Account
System landing page for the access.
c. 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. A minimal page with a list of existing services associated with the user
and a button for adding new services should help.
b. Clicking on the aforementioned button should lead people to the page for
adding new services.
c. Clicking on the gear icon beside an existing service element should take
them to the page where it can be updated.
d. Clicking on the message icon beside an existing service element should
take them to the associated messages page.
e. Clicking on the log out button from the avatar icon should revoke access
and take the users to the landing page.
f. 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. A minimal page with the appropriate fields required to create a new
service and buttons to save or cancel should help.
b. Pressing the save button should send those contents to the API service
and take users to the listing page.
c. Pressing the cancel button should not interact with the API service and
simply take users to the listing page.
d. An alert section or modal should be used to inform users of any issues
with the form filled or the response received.
e. Clicking on the log out button from the avatar icon should revoke access
and take the users to the landing page.
f. 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. A minimal page with the appropriate fields required to edit an existing
service and buttons to save or cancel should help.
b. Pressing the save button should send those contents to the API service
and take users to the listing page.
c. Pressing the cancel button should not interact with the API service and
simply take users to the listing page.
d. An alert section or modal should be used to inform users of any issues
with the form filled or the response received.
e. Clicking on the log out button from the avatar icon should revoke access
and take the users to the landing page.
f. 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. A minimal page with a list of message entries associated with the said
service and a back button should help.
b. Pressing the back button should not interact with the API service and
take the users back to the listing page.
c. Clicking on the message should take them to the Datagrepper page
associated with the message signature.
d. A count of the messages should be available on the header and effective
pagination should be implemented.
e. Clicking on the log out button from the avatar icon should revoke access
and take the users to the landing page.
f. This is only visible to people who have logged in the service and those
who have not will be redirected to the landing page.
Recommendations
---------------
1. `VueJS <https://vuejs.org/>`_
2. `ReactJS <https://react.dev/>`_