95 lines
3.1 KiB
ReStructuredText
95 lines
3.1 KiB
ReStructuredText
.. _the_action_plan:
|
|
|
|
The Action Plan
|
|
===============
|
|
|
|
Elements involved
|
|
-----------------
|
|
|
|
This implementation of the Webhook To Fedora Messaging service project requires
|
|
the involvement of the following entities.
|
|
|
|
Frontend service
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
frsv
|
|
|
|
1. The frontend service is expected to allow for the operations of managing per
|
|
user account details using a supported browser.
|
|
2. It is recommended to use progressive web framework like ReactJS or VueJS to
|
|
detach the frontend and backend system elements.
|
|
3. The deployment is suggested to be done either in the same device as the API
|
|
service or at least in the same network.
|
|
4. The service should be exposed on the public internet and needs to be behind
|
|
Fedora Account System authentication check.
|
|
|
|
Database service
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
dber
|
|
|
|
1. The database service is expected to allow for creating, reading, updating
|
|
and deleting webhook forwarding requests per user.
|
|
2. It is recommended to use an structured database management service like
|
|
Postgres with an asynchronous means of communication.
|
|
3. The deployment is suggested to be done either in the same device as the API
|
|
service or at least in the same network.
|
|
4. The service should not be exposed on the public internet and any interactions
|
|
with the service should be resolved internally.
|
|
|
|
API service
|
|
^^^^^^^^^^^
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
apis
|
|
|
|
1. The API service is expected to manage requests for creating messages on the
|
|
Fedora Messaging bus for the interacting users.
|
|
2. It is recommended to use an asynchronous web framework like FastAPI or
|
|
Litestar with object relationship model support.
|
|
3. The deployment is suggested to be done either in the same device as the
|
|
database service or at least in the same network.
|
|
4. The service should be exposed on the public internet and needs to be behind
|
|
Fedora Account System authentication check.
|
|
|
|
API documentation
|
|
^^^^^^^^^^^^^^^^^
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
apid
|
|
|
|
1. The API documentation is expected to elucidate how a contributor can
|
|
leverage the API service to send messages on the bus.
|
|
2. It is recommended to let the choice be dependent on the API service
|
|
technological stack for automation and convenience.
|
|
3. The deployment is suggested to be done either in the same device as the API
|
|
service or at least in the same network.
|
|
4. The service should be exposed on the public internet but needs not be behind
|
|
a Fedora Account System authentication check.
|
|
|
|
Message producer
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
mpro
|
|
|
|
1. The message producer is expected to interact with the Fedora Messaging bus
|
|
by sending messages requested by the API service.
|
|
2. The Fedora Messaging library is a good fit for interacting with the service
|
|
but asynchronous processing is greatly advised.
|
|
3. The deployment is suggested to be done either in the same device as the API
|
|
service or at least in the same network.
|
|
4. The service should not be exposed on the public internet and any interactions
|
|
with the service should be resolved internally.
|