Proposal: Frontend plugins

[Haarolean]

Column	Value
Status	Undecided
Impact	High
Driver	Need to provide API to include third party functionality to the app on frontend
Approver	-
Contributors	@Leshe4ka @Haarolean @germanosin
Started	21.04.24
Due date	-
Outcome	-

Background

Context and Solution Overview
In the realm of modern web development, embracing microfrontend architecture offers a granular approach to building scalable and maintainable applications. This proposal delves into the utilization of web components for constructing a microfrontend, specifically focusing on a remote application that integrates seamlessly with a host application.

Development Requirements for the Remote Application
The remote application is tasked with exporting an initialization function, which the host application will invoke. The core functionality of this function involves rendering application within a ShadowRoot container, ensuring style encapsulation and routing isolation.

Initialization Function Overview (React example)
Below is the initMicro script that outlines the initialization process:

import ReactDOM from "react-dom/client";
import React from "react";
import RemoteApp from "./RemoteApp";

const initMicro = (shadowRoot: ShadowRoot, routerBaseName: string) => {
  const container = shadowRoot.getElementById("root") || document.createElement("div");
  const styles = document.createElement("div");
  shadowRoot.appendChild(styles);
  const root = ReactDOM.createRoot(container);

  root.render(<RemoteApp styleContainer={styles} routerBaseName={routerBaseName} />);
};

export { initMicro };

The initMicro function accepts two parameters:

1. shadowRoot (Shadow DOM MDN): A container for the application's HTML content, ensuring style and script encapsulation.
2. routerBaseName: Specifies the base path for resolving routes within the microfrontend, critical for correct routing integration with the host application.

Bundle Configuration and Asset Management
To optimize loading and ensure correct asset serving, the remote application must configure its bundler to set a base path relative to its deployment location. For example, using Vite:

import { defineConfig } from "vite";

export default defineConfig({
  base: "./",
  build: {
    rollupOptions: {
      output: {
        chunkFileNames: (chunkInfo) => {
          if (chunkInfo.name === "initMicro") {
            return "initMicro.js";
          }

          return "[name]-[hash].js";
        },
      },
    },
  },
  
  ... // other config params
});

Styling Considerations
Styles within the remote application should reside inside the Shadow DOM to avoid conflicts and ensure correct application. Ideally, a single CSS file linked in the index.html suffices. If external libraries are used for styling (e.g., styled-components), they must support targeting elements within the Shadow DOM.

Choosing External Libraries
Selecting external libraries that interact with the DOM must be done with caution. These libraries should support rendering within the Shadow DOM or provide APIs to specify rendering containers (e.g., RadixUI). Libraries that default to manipulating the document's DOM directly could lead to functionality loss or style misapplication.

Challenges and Potential Issues

• Shadow DOM Integration: Ensuring all components and styles function correctly within a ShadowRoot can be challenging, particularly with third-party libraries not designed with Shadow DOM in mind.
• Routing: Coordinating routing between the host and remote applications requires careful implementation to ensure seamless navigation.
• Performance: Loading and initializing the remote application must be optimized to avoid performance bottlenecks, particularly in a microfrontend landscape where multiple applications coexist.

Configuration File for Host Application Interaction
To streamline the integration process between the host and remote applications, a configuration file, RemoteAppConfig, is essential. This configuration will guide the host application on how to locate, initialize, and render the remote applications within its environment.

Configuration File Structure
The configuration file is structured as follows:

interface RemoteAppConfig {
  apps: RemoteApp[];
}

interface RemoteApp {
  name: string; // The web component name, e.g., "remote-app"
  indexHTMLUrl: string; // Path to the index.html file, e.g., "https://your-site.com/index.html"
  initScriptUrl: string; // Path to the initialization script file, e.g., "https://your-site.com/initMicro.js"
  initScriptName: string; // Name of the exported initialization function, e.g., "initMicro"
  baseUrl: string; // e.g., "https://your-site.com/"
  route: RemoteRoute;
  tab: RemoteTab;
}

interface RemoteRoute {
  path: string; // Used in the UI routing to access the remote application, e.g., "your-site-ui"
}

interface RemoteTab {
  text: string; // Text displayed on the navigation button
  path: string; // Same as path in RemoteRoute
}

Configuration Utilization

• Host Application Processing: The host application uses this configuration to dynamically load and render remote applications. It fetches the index.html and the initialization script as defined, initializing each remote app within its designated container.
• Dynamic Initialization: By referencing initScriptUrl and initScriptName, the host application dynamically imports and invokes the initialization function, effectively bootstrapping the remote application.
• Routing and Navigation: The route and tab objects within the configuration enable the host application to integrate the remote application's routing seamlessly and provide user-friendly navigation options.

Benefits

• Scalability: Adding new remote applications or updating existing ones can be done by simply modifying the configuration file, without the need to alter the host application's codebase.
• Decoupling: This approach fosters a loosely coupled architecture, where the host and remote applications can evolve independently, enhancing maintainability.
• Dynamic Integration: The host application can conditionally load remote applications based on runtime criteria, optimizing resource usage and performance.

Conclusion
This proposal outlines a structured approach to integrating a remote application within a microfrontend architecture using web components. By adhering to the outlined practices, the development team can create isolated, maintainable, and scalable microfrontends that enhance the overall application architecture.

Options considered

	Option 1: Web Components	Option 2: Framework-Specific Microfrontends	Option 3: Single Framework Microfrontends
Description	Utilize web components to build encapsulated microfrontends.	Leverage Module Federation for dynamic script loading and app integration at runtime.	Use iframes to isolate microfrontends within the host application.
Pros and Cons	Pros: 1. Framework-agnostic. 2. Encapsulates styles and behavior. 3. Reusable across different applications. Cons: 1. Learning curve for new users. 2. Variability without strict conventions. 3. May require custom tooling for advanced features.	Pros: 1. Shared dependencies reduce load times. 2. Enables dynamic runtime integration. 3. Ideal for applications using the same framework. Cons: 1. Tied to Webpack. 2. Complexity in setup and configuration. 3. Limited to JavaScript-based applications.	Pros: 1. Complete isolation ensures no style or script conflicts. 2. Simple to implement with basic HTML knowledge. 3. Framework and language agnostic. Cons: 1. Overhead from multiple DOM trees. 2. Challenging to communicate between iframes. 3. Can affect the performance if not managed properly.

Outcome

Objective: The proposal aims to integrate web components into the microfrontend architecture, leveraging their encapsulation and framework-agnostic features to enhance modularity, reusability, and maintainability of the application ecosystem.

Key Outcomes:
Enhanced Modularity:
Web components will provide a high degree of encapsulation, ensuring that individual microfrontends can be developed, updated, and maintained independently, reducing cross-team dependencies and streamlining the development process.

Framework Agnosticism:
The use of web components allows for flexibility in choosing or changing underlying frameworks or libraries across different microfrontends, facilitating a more adaptable and future-proof architecture.

Scalability and Performance:
By isolating microfrontends within web components, the proposal supports scalable and performant applications, enabling efficient loading and interaction without interference among components.

[siegenthalerroger]

Just wanted to chime in with a possible use-case for this, allowing custom functionality to be added to consumer management (in this example, "pausing" of consumers).

We have instrumented our (spring) kafka clients to have the capability of remotely being paused (or stopped). To achieve this, the clients consume a special internal topic, within which requested changes in the state of a consumer are stored. If we could have the capability of producing a message into this topic from a button in the UI (situated within the list of consumers, analagously to the offset management) this would be ideal.