UI Middleware

Provides the collected manifest.json of services in a cluster as well as a list of dependencies for each source file. This information can be used to dynamically compile all ui components at runtime in the browser. Besides serving the information about all resources, this service can also function to provide snapshots of all the resources available at a specific point in time.

Architecture

The UI Middleware is, as the name already suggests, a middleware component to support the App Suite UI. As an installation of App Suite UI can consist of multiple projects, like the Core App Suite UI, Documents UI, OX Guard UI, and other custom plugins, those components need to be combined at some point to be served to the browser. This is handled by the ui-middleware component, by putting it between the Ingress Controller and the containers serving the individual components that make up the App Suite UI.

If you prefer a picture, this is, how such an installation can look like.

Prerequisites

• A Redis server is required (standalone, sentinel and cluster mode supported)

Deployments

Kubernetes

cd helm
helm upgrade -i -f ui-middleware/values.yaml -f values/develop.yaml ui-middleware ./ui-middleware

It is possible to horizontally scale the UI Middleware, as more clients are fetching resources from this service. Each instance maintains a cache of all files locally (in memory), allowing to scale easily.

Configuration

Config Map

# List of urls where to find ui containers
baseUrls:
  - http://service.namespace.svc.cluster.local/
# optional, when this number is changed, the changes on clients will be invalidated and will reload the ui-sources
salt: '1234'

Ingress

When using Ingress to make the service available to the public, the service is intended to be configured as a "fallback" or "default" service to answer all requests that are not specified to be served by one of the other services (e.g like everything under /api). This should simplify the Ingress configuration. One example can be found in the ui-middleware repository.

Some notes on code loading

It is mandatory to load the UI over https with a valid certificate and there are multiple reasons for that. These notes give an overview over the features that are required for code loading and will substantiate the need for https.

• First of all, securing your site with https is not hard anymore. We have e.g. Let's Encrypt and several other ways to achieve this. But which case applies to a use-case is not part of these notes.
• The UI needs a service worker to function. The service worker is used for file-caching and version-mismatch detection (the "reload"-banner). Service workers are only loaded over https with valid certificate to prevent man-in-the-middle attacks.
• The UI consists of many small files, because it cannot be bundled as before. To improve file transfer time, HTTP/2 is required which requires https.
• The service worker also increases boot time by loading zipped chunks of files and puts them in the browser-cache on initial boot. Without https no service worker, without service worker no zipped loading.
• To reduce the transferred file-size, the UI-middleware uses brotli encoding for every transferred file (except the index.html). The UI-middleware will not check for accept-encoding headers due to performance reasons. Modern browsers will not load brotli over insecure connections and the UI won't load without it.

It is noteworthy that localhost is an exception to the above rules and the UI including service workers and preloading (but not http2) will work on localhost for development environments.

Redis default setup

For setups where scaling of the UI middleware is not necessary you can use the default values of the helm chart, which will deploy a redis server as a sidecar container.