Custom RSD homepage for partners

[dmijatovic]

Two of our partners, who actively contribute to RSD development have expressed need for a completely custom home page / landing page.

Current approach for having custom home page

Currently we implemented host property in the settings.json and the conditional to load different home page components based on values helmholtz or rsd. All components, including custom Helmholtz components, are stored in the main/core rsd repository at location /frontend/components/home/**.

Another partner would also like to use custom home page. They do not have sufficient knowledge of React to be able to integrate their custom home page using current approach. Either we use different approach or provide support for React/Next custom homepage implementation.

In addition, both partners would like to have more flexibility concerning the custom home page. They would prefer to have their custom home page not committed to main rsd repository, rather stored within their own infrastructure for more flexibility. For example, with the current approach each change on their custom homepage would need to be approved by core rsd team, merged into main RSD repo and then released by core RSD team.

Two alternative approaches

I see two major directions we can take:

• static separation of home and other routes using NGINX proxy services: minor changes might be needed in the core RSD
• dynamic loading of modules during the runtime using webpack's module federation: significant structural changes need to be made in core RSD project (spliting frontend code into multiple modules and setting up monorepo structure for frontend part)

Static loading of different modules/docker images using NGINX configuration

Out partners could apply proxy routing to different modules (docker images) using NGINX configuration. This implies that our partners also use our NGINX reverse proxy definitions in production.

Route "/" to different app

In this scenario we could continue to use core rsd home page but the partners could setup additional NGINX route to mount a different application at "/" location. My initial tests on NGINX configuration show that homepage is then limited to index.html and only embedded assets. I am not an expect in NGINX. More suitable solution might be achieved by someone with more NGINX knowledge.

Redirect to "/home" for different app

In this scenario our partners could redirect "/" to "/home" location. The advantage is that other assets (css, js etc) then can be easier loaded on home route (css,js, etc.).

Dynamic loading of modules (module federation / micro frontends)

This is fairly recently developed approach that enables dynamical loading of the componets/pages from the remote location. It requires webpack, although there seem to be some support added in Vite too. It is framework agnostic but does require use of webpack (or Vite) in all modules that want to communicate/share pages.

Multiple ui modules in core RSD

In order to achieve more flexibility we can split current front end code into a number of independent modules. The modules should share settings (incl. theme), utility functions and "core" components. The settings are generic (settings.json) and can be loaded into any "tool/library". Utility functions are somewhat generic and can be used in any JavaScript project. The core components are specific to React/Material UI approach.

The possible modules could be:

• home-ui: handles homepage
• software-ui: handles /software route and all subsequent routes (eq. /software/{id}/edit/contributors)
• projects-ui: handles /projects route and all subsequent routes (eq. /projects/{id}/edit/contributors)
• organisations-ui: handles /organisations route and all subsequent routes (eq. /organisations/{id}/{...id}/software)
• user-ui: handles /user route and all subsequent routes (eq. /user/software)
• admin-ui: handles /admin route and all subsequent routes (eq. /admin/rsd-users)
• ui-components: core components used by all modules (eq. AppHeader, AppFooter etc.)
• ui-settings: shared settings during runtime, but also dev settings (tailwind.config, eslint.config, jest.config etc.)
• ui-utils: shared utility functions (eg. logger, getBaseUrl etc.)