[EPIC](greenhouse): Architecture and Modularization

[edda]

Description

This epic gathers all the tasks necessary to achieve the goal of reworking the architecture of the Greenhouse Dashboard. While there is an existing version of the dashboard, it has significant architectural weaknesses that make further development difficult and inefficient.

To address these issues, we initiated a new project called Carbon, which will serve as a re-implementation of the Greenhouse Dashboard, fixing the architectural shortcomings. The work will be divided into smaller tasks to ensure a structured and manageable approach.

The development will follow the requirements outlined in this [Document]. The immediate priority is to implement the loading mechanism for our standalone apps — Supernova, Doop, Heureka, and core modules — and to establish a clear and standardized interface.

Note: All new development should be done in TypeScript to ensure type safety, maintainability, and improved developer experience.

1. Key Proposals

1.1 Architecture for Extensions and Modules

The architecture for the Greenhouse Dashboard is built around a modular system comprising Core Modules and Extensions. The following proposals outline the key components of this architecture:

• Modular Design:
  The architecture should enable interchangeable and configurable modules and extensions, facilitating scalability and adaptability to future needs without significant architectural changes. To achieve this, clear interfaces and abstractions (e.g., an apiWrapper) must be established to standardize communication and interaction between modules and extensions.

• Dashboard (Host):
  The Dashboard must implement an effective loading mechanism to support the integration of extensions seamlessly. This mechanism should accommodate both colocated and remote extensions. Additionally, the Dashboard will oversee essential functionalities, including authentication, module and extension loading, and shared services such as URL state management and navigation.

• Extensions:
  The architecture must support a diverse range of extensions, including internal extensions developed specifically for the Dashboard and third-party extensions. This includes the ability to integrate various types of extensions, such as static builds and iframes, ensuring flexibility and extensibility within the system.

1.2 Routing Mechanism

• Dashboard:
  Extensions should have dedicated, isolated routes that prevent interference with the host platform. Route parameters and query parameters will allow dynamic data handling within the extensions.
  • Deep linking support is crucial to allow users to directly access specific views in an extension.

1.3 Loading Mechanism and Isolation

• Dashboard:
  The Dashboard will utilize a unified loading mechanism defined by a clear interface, such as mount(containerElement, options). Each extension must implement and export this method, allowing seamless integration of various technologies like React, Vue, or even iframes. The options parameter can include application props and additional objects, such as a communication manager. This approach enables both colocated and remote applications to be dynamically loaded and rendered, as well as supporting iframes through the mount method. Additionally, the system will incorporate lazy loading and dynamic updates from manifests to optimize performance and resource utilization.

• Extension Isolation:
  To ensure full isolation, extensions must not be allowed to manipulate the host environment in detrimental ways. This includes preventing extensions from affecting the core functionalities or state of the Dashboard. Additionally, if an extension encounters an error, it should fail gracefully without compromising the overall stability of the dashboard. This approach helps maintain the integrity of the system while allowing extensions to operate independently.

1.4 Communication

The Dashboard will establish a robust communication channel to facilitate interactions between the host platform and extensions, as well as among extensions themselves. This can be implemented through a shared communication object or agent, accessible to all extensions. Alternatively, an npm package may be developed for easier integration. A message-passing mechanism (e.g., postMessage) will enable two-way communication, particularly beneficial for iframe-based extensions.

Communication protocols will be designed to ensure seamless interactions among all components while maintaining the overall integrity of the system.

---

2. Security Considerations

Security is essential for loading external extensions in the Greenhouse Dashboard, especially with remote or iframe-based applications. The following measures will be implemented:

• Sandboxing: All iframe-based extensions will be sandboxed to prevent malicious scripts from impacting the host or other extensions.
• CSP and CORS Policies: Strict Content Security Policies (CSP) and Cross-Origin Resource Sharing (CORS) settings will ensure that only trusted domains can load extensions.
• Controlled Interaction: Extensions will be prevented from manipulating each other directly; interactions will occur solely through agents provided in the options parameter, utilizing well-defined interfaces.
• Authentication & Authorization: The system will initially use OIDC-based authentication, with a design that allows for future replacement or integration of different authentication mechanisms.

These measures will help ensure a secure and stable environment for the Greenhouse Dashboard and​ its extensions.

Tasks

• [TASK](carbon): Implement the layout for the Greenhouse Dashboard based on the current dashboard #552
• [TASK](carbon): Develop the loading mechanism for extensions, focusing on Supernova #553
• [TASK](carbon): Implement routing and state management in the URL to support deep linking #551
• [TASK](carbon): Establish sandboxing for extension isolation #554
• [TASK](carbon): Implement authentication for the Greenhouse Dashboard #555
• [TASK](carbon): Create an abstraction layer for the Kubernetes API #556
• [TASK](carbon): Build the admin core module for management functions #557

Related Issues:

• [EPIC](greenhouse): Design Workshop for Defining Business Requirements of Greenhouse Admin Area #544
• [SPIKE](Carbon): Carbon research routing task #505