Define and implement a TruX UI strategy

[lennartploen]

How should a user access and switch between TruX applications and their data ? Currently, TruSupply will be used by FAS and KfW and (as per request) will run on the same blockchain (node and API). Front ends will be different though between different TruX applications given different use cases (projects, budget in trubudget vs. shipments, condition of products etc. in TruSupply).

Different scenarios need to be discussed, e.g.
(1) One single TruX URL per blockchain that allows to select between different TruX Front ends -> can be done in the context of trusupply as an example
(2) fully integrate different TruX UI into one single UI using different "switch" buttons -> Risk of becoming very complicated as soon as their different TruX applications and modules available in the future
(3) ...

[jzakotnik]

Option 2 seems to be too complex and monolithic (e.g. difficult to maintain).
Option 1 could work if each registered app provides an app ID or tag to the API and therefore later each frontend can receive the data from the frontend that is relevant for that registered app.

[stale]

This issue has been automatically marked as stale because it has not had activity for 30 days. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.