...
In order to understand the architecture, it is important to understand the concept of micro-frontends. This can be shown by showing how a user is presented with the KAM solution:
When a user accesses the KAM frontend, they are accessing a web application (single page app or SPA) like this:
Here they can push the green button to logon on using the FUT infrastructure IdP, like this:
After login, they are presented with a selection on of the security context they would like to use in KAM. This selection will determine the set of micro-frontend they have access to.
After this selection, the user is able to use KAM and its modules with the individual micro frontends. This is shown below:
...
The top bar, with
main navigation links'
security context selection
log off functionality
The left menu bar which gives the user the possibility to
select different micro-frontends like careteam and questionnaire
...
The table listing the careteams (they the gray area in the screen) is a separate micro-frontend which that is assembled by the browser within the shell application. This micro frontend is a separate component in the FUT infrastructure , but is assembled by the shell application for the user. Now that we have a basic understanding of the roles of a shell application, a an identity provider (IdP), and a micro frontend, we can have a look at how this has been deployed as individual components in the FUT infrastructure.
...
The component model of the KAM architecture
In order to describe what has been built and deployed, and how the components interact, we will start of with a diagram with the two main areas of components in the FUT infrastructure cluster. All components are still packaged and released as containers, as every other component on the infrastructure.
...
Shell frontend
The shell frontend is a single-page app. It handles security and routing to the individual micro-frontends. The user accesses the shell and from there they can navigate through a menu to the individual micro-frontends. The user never leaves the shell application, but different micro-frontends can be shown. The connection between the shell application and the micro-frontends is very loosely coupled, and only through the users user's browser. For further information on micro frontends see https://micro-frontends.org/ . The shell application is hosted as a container with a an Nginx server, to enable the browser to load the shell frontend. The shell frontend-only really runs in the users user's browser. The way these micro-frontends are loaded into the shell application, is facilitated by the tool Webpack, see also Micro frontends - eHealth Infrastructure Wiki - Confluence (atlassian.net) and Concepts | webpack
The micro-frontends are not loaded before they are needed, in order to maximize the performance of the user expirienceexperience. As there can be many micro-frontends pre-fetching would come with a bigger and bigger penalty.
Micro frontend
The micro-frontends expose a frontend, tailored to show resources from a single infrastructure service. Currently, there are three micro-frontends: careteam, questionnaire, and plan. These micro-frontends are exposed by the shell-frontend , and use infrastructure services to deliver resources to the end-user. For more information on how to interface from micro-frontend to shell application, read this page: Micro frontends - eHealth Infrastructure Wiki - Confluence (atlassian.net).
The individual micro frontends are hosted as a containers container with each their Nginx server, to enable the browser to load the specific micro-frontend. The individual micro-frontend only runs in the users user's browser.
Common pickers
Among the micro-frontends, there are is a need for a shared set of pickers, to make it possible to select and an organization, create a timing expression, set measurement thresholds, etc. For this, a module has been created. The micro-frontends include this module and invoke it using messages in the browser, and will also receive the picked value/setting through a message. For more information on how to utilize pickers from the KAM project, have a look here: Kam-pickers - eHealth Infrastructure Wiki - Confluence (atlassian.net). The set of pickers are is hosted as a container with each its own Nginx server, to enable the browser to load the pickers. The pickers only really run in the users user's browser.
Infrastructure services
The remaining services are all infrastructure services
...