Portal & GraphQL Analysis¶

This document analyzes the Platform Mesh Portal components to assess operational complexity, customization possibilities, and contributing potential.

Detailed Component Documentation

For in-depth information about each component, see the detailed documentation:

OpenMFP Framework - Configuration-driven micro frontend platform
Luigi Framework - Enterprise micro frontend framework by SAP
GraphQL Gateway - Kubernetes GraphQL API gateway
Platform Mesh Portal Integration - How Platform Mesh uses OpenMFP

Executive Summary¶

Component Assessment Overview

Quick assessment of Platform Mesh Portal components for operational viability and customization potential:

Component	Complexity	Modularity	Contributing	Recommendation
OpenMFP Portal	Medium-High	High	Medium	Evaluate carefully
Luigi Framework	Medium	High	Good	✅ Viable
GraphQL Gateway	Medium	Medium	Limited	Use as-is
Extension Manager	Low-Medium	High	Good	✅ Viable
User Management	Medium	Medium	Limited	Configure, don't extend

Component Analysis¶

1. OpenMFP Portal¶

Repository: github.com/openmfp

Architecture Overview¶

OpenMFP (Open Micro Frontend Platform) is an enterprise micro frontend solution that serves as the portal foundation for Platform Mesh.

┌─────────────────────────────────────────────────────────────────┐
│                        OpenMFP Portal                           │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐  │
│  │ Luigi Core  │  │ Portal UI   │  │ Content Configurations  │  │
│  │ (Routing)   │  │ (Angular)   │  │ (Extension Registry)    │  │
│  └─────────────┘  └─────────────┘  └─────────────────────────┘  │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────────────────────────────────────────────────────┐│
│  │              Micro Frontend Extensions (iframes)            ││
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐        ││
│  │  │ Accounts│  │Workspace│  │Marketplace│ │ Custom  │        ││
│  │  │   MFE   │  │   MFE   │  │   MFE    │ │  MFEs   │        ││
│  │  └─────────┘  └─────────┘  └─────────┘  └─────────┘        ││
│  └─────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘

Technology Stack¶

Layer	Technology	Version
UI Framework	Angular	17+
MFE Framework	Luigi	Latest
Language	TypeScript	5.x
Build	Webpack/Vite	-
Container	Node.js	20 LTS

Complexity Assessment¶

Aspect	Rating	Details
Codebase Size	Medium	~15,000+ LOC across repositories
Dependencies	Medium	~50 direct dependencies
Learning Curve	Medium-High	Requires Luigi + Angular expertise
Configuration	High	Extensive configuration options
Operational	Medium	Standard K8s deployment

Modularity¶

Strengths: - Extension-based architecture - nearly every feature is pluggable - Technology-agnostic micro frontends (React, Angular, Vue, etc.) - Well-defined service interfaces - Content configuration for code-only extension registration

Extension Points:

# Example ContentConfiguration for custom MFE
apiVersion: core.platform-mesh.io/v1alpha1
kind: ContentConfiguration
metadata:
  name: my-custom-extension
spec:
  inlineConfiguration:
    contentType: yaml
    content: |
      name: my-extension
      luigiConfigFragment:
        data:
          nodes:
            - pathSegment: my-feature
              label: My Feature
              urlSuffix: /index.html

Contributing Potential¶

Area	Feasibility	Effort
Bug fixes	Good	Low
New MFE extensions	Good	Medium
Core framework changes	Difficult	High
UI customizations	Medium	Medium

Contributing Process:

Apache 2.0 License
Standard GitHub workflow (fork, PR)
REUSE compliance required
Code review by maintainers (SAP)

Learn More About OpenMFP

For comprehensive documentation including architecture, configuration examples, and best practices, see:

→ OpenMFP Framework Documentation

2. Luigi Microfrontend Framework¶

Repository: github.com/luigi-project/luigi Documentation: luigi-project.io

Architecture Overview¶

Luigi is SAP's open-source micro frontend framework that provides the shell for composing multiple applications.

┌─────────────────────────────────────────────────────────────────┐
│                       Luigi Core                                │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐  │
│  │ Navigation  │  │ Routing     │  │ Authentication          │  │
│  │ Management  │  │ Engine      │  │ Handler                 │  │
│  └─────────────┘  └─────────────┘  └─────────────────────────┘  │
├─────────────────────────────────────────────────────────────────┤
│                       PostMessage API                           │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────────────────────────────────────────────────────┐│
│  │                 Luigi Client (in iframes)                   ││
│  │  - linkManager() - navigation                               ││
│  │  - uxManager() - UI controls                                ││
│  │  - sendCustomMessage() - communication                      ││
│  └─────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘

Core Concepts¶

Concept	Description
Navigation Nodes	Define application structure and routing
Contexts	Share data between shell and micro frontends
View Groups	Group related micro frontends for preloading
Authorization	Visibility rules for navigation elements

Technology Stack¶

Component	Technology
Core	Vanilla JavaScript/Svelte
Client Libraries	Angular, React, Vue, Web Components
Communication	PostMessage API (iframe isolation)
Styling	CSS, SCSS

Community Health¶

Metric	Value
GitHub Stars	903
Forks	177
Contributors	64
Releases	155
Open Issues	36
License	Apache 2.0
Last Release	Dec 2025 (v1.7.6)

Complexity Assessment¶

Aspect	Rating	Details
Learning Curve	Medium	Good documentation, clear concepts
Configuration	Medium	JSON-based, well-documented
Integration	Low	Client libraries for major frameworks
Maintenance	Low	Stable API, backward compatible

Configuration Example¶

Luigi.setConfig({
  navigation: {
    nodes: [{
      pathSegment: 'home',
      label: 'Home',
      viewUrl: '/microfrontends/home.html',
      children: [{
        pathSegment: 'accounts',
        label: 'Accounts',
        viewUrl: '/microfrontends/accounts.html'
      }]
    }]
  },
  auth: {
    use: 'openIdConnect',
    openIdConnect: {
      authority: 'https://keycloak.example.com/realms/myrealm',
      client_id: 'my-client'
    }
  }
});

Contributing Potential¶

Area	Feasibility	Notes
Bug fixes	Good	Active community
Client libraries	Good	Angular, React, Vue support
Plugins	Good	Plugin architecture exists
Core changes	Medium	Requires deep understanding

Learn More About Luigi

For detailed documentation including API reference, configuration examples, and integration patterns, see:

→ Luigi Framework Documentation

3. Kubernetes GraphQL Gateway¶

Repository: github.com/platform-mesh/kubernetes-graphql-gateway Helm Chart Version: 0.27.2 (appVersion v0.3.4)

Architecture Overview¶

A dual-component system that translates GraphQL queries into Kubernetes/KCP API calls.

┌─────────────────────────────────────────────────────────────────┐
│                  kubernetes-graphql-gateway                     │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────────────────┐  ┌─────────────────────────────┐   │
│  │      Gateway            │  │       Listener              │   │
│  │  (Port 8080)            │  │  (Port 8090)                │   │
│  │                         │  │                             │   │
│  │  - GraphQL endpoint     │  │  - Watch K8s resources      │   │
│  │  - Schema serving       │  │  - Build GraphQL schema     │   │
│  │  - Query execution      │  │  - CRD discovery            │   │
│  │  - User impersonation   │  │  - Virtual workspaces       │   │
│  └─────────────────────────┘  └─────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    KCP / Kubernetes API                         │
└─────────────────────────────────────────────────────────────────┘

Key Features¶

Feature	Description
Dynamic Schema	Auto-generates GraphQL schema from K8s/KCP CRDs
User Impersonation	Forwards user identity for authorization
Virtual Workspaces	Supports KCP workspace navigation
GraphiQL	Built-in GraphQL IDE (configurable)
Tracing	OpenTelemetry integration

Configuration (from Helm values)¶

gateway:
  port: 8080
  graphiql: true                    # Enable GraphiQL IDE
  shouldImpersonate: true           # Forward user identity
  introspectionAuthentication: true # Require auth for introspection
  usernameClaim: email              # JWT claim for username

listener:
  apiExportName: kcp.io
  port: 8090
  virtualWorkspacesConfig:
    enabled: false                  # Enable virtual workspace support

Complexity Assessment¶

Aspect	Rating	Details
Codebase	Medium	Go-based, moderate size
Configuration	Low	Well-documented Helm values
Operational	Low	Standard K8s deployment
Customization	Limited	Schema is auto-generated

Resource Requirements¶

resources:
  gateway:
    limits:
      memory: 1200Mi
    requests:
      cpu: 250m
      memory: 1000Mi
  listener:
    limits:
      memory: 600Mi
    requests:
      cpu: 250m
      memory: 500Mi

Contributing Potential¶

Area	Feasibility	Notes
Bug fixes	Medium	Requires Go expertise
Schema extensions	Limited	Auto-generated from CRDs
Performance tuning	Medium	May need deep K8s knowledge

Learn More About GraphQL Gateway

For comprehensive documentation including GraphQL basics, query examples, and deployment guide, see:

→ Kubernetes GraphQL Gateway Documentation

4. Extension Manager Operator¶

Repository: github.com/platform-mesh/extension-manager-operator Helm Chart Version: (embedded in platform-mesh)

Architecture Overview¶

Kubernetes operator that manages micro frontend extensions for the portal.

┌─────────────────────────────────────────────────────────────────┐
│               Extension Manager Operator                        │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────────────────┐  ┌─────────────────────────────┐   │
│  │    Controller           │  │    Validation Server        │   │
│  │                         │  │    (Port 8088)              │   │
│  │  - Watch CRs            │  │                             │   │
│  │  - Reconcile state      │  │  - /validate endpoint       │   │
│  │  - Update status        │  │  - Content validation       │   │
│  └─────────────────────────┘  └─────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│              ContentConfiguration CRD                           │
│  - Inline content (YAML/JSON)                                   │
│  - Remote content (URL with auth)                               │
│  - Status conditions (Ready, Valid)                             │
└─────────────────────────────────────────────────────────────────┘

Custom Resource Definition¶

apiVersion: core.platform-mesh.io/v1alpha1
kind: ContentConfiguration
metadata:
  name: my-extension
spec:
  # Option 1: Inline configuration
  inlineConfiguration:
    contentType: yaml  # or json
    content: |
      name: my-extension
      luigiConfigFragment:
        data:
          nodes:
            - pathSegment: my-feature
              label: My Feature

  # Option 2: Remote configuration
  remoteConfiguration:
    url: https://example.com/config.yaml
    contentType: yaml
    authentication:
      type: bearer
      secretRef:
        name: my-auth-secret
status:
  conditions:
    - type: Ready
      status: "True"
    - type: Valid
      status: "True"

Complexity Assessment¶

Aspect	Rating	Details
Codebase	Low-Medium	Standard K8s operator pattern
Configuration	Low	Simple CRD structure
Operational	Low	Stateless operator
Extension	Good	Add new CRDs easily

Contributing Potential¶

Area	Feasibility	Notes
New CRD types	Good	Standard operator development
Validation rules	Good	Extend validation server
Integration	Good	Well-defined interfaces

Learn More About Extension Manager

For complete documentation including CRD specifications, configuration examples, and best practices, see:

→ Extension Manager Operator Documentation

Architecture Overview¶

┌─────────────────────────────────────────────────────────────────┐
│                    Identity & Access Layer                      │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐  │
│  │    Keycloak     │  │   OpenFGA       │  │ Security        │  │
│  │    (IdP)        │  │   (ReBAC)       │  │ Operator        │  │
│  │                 │  │                 │  │                 │  │
│  │ - Authentication│  │ - Authorization │  │ - Tuple mgmt    │  │
│  │ - User mgmt     │  │ - Relationships │  │ - Realm setup   │  │
│  │ - Self-signup   │  │ - Permissions   │  │ - Sync          │  │
│  └─────────────────┘  └─────────────────┘  └─────────────────┘  │
└─────────────────────────────────────────────────────────────────┘

User Management (Keycloak)¶

Platform Mesh uses Keycloak for identity management with organization-based multi-tenancy.

Key Features¶

Feature	Implementation	Configurable
User Registration	Keycloak self-registration	Yes
Email Verification	Keycloak email flow	Yes
Password Policies	Keycloak realm settings	Yes
MFA	Keycloak authenticators	Yes
SSO	OIDC/SAML	Yes
Social Login	Keycloak identity providers	Yes

Organization Onboarding Flow¶

Based on the E2E test analysis:

1. User visits portal.dev.local
2. User clicks "Register" → Keycloak registration form
3. Email verification sent → User clicks link
4. Welcome page: "Welcome to the Platform Mesh Portal!"
5. User enters organization name → Clicks "Onboard"
6. Organization-specific realm created
7. User invited to organization → Email sent
8. User sets password for organization realm
9. User logged into organization subdomain (org.portal.dev.local)

Configuration Points¶

# Keycloak realm configuration via Crossplane
auth:
  default:
    discoveryUrl: "https://keycloak.example.com/realms/platform-mesh"
    clientId: "portal"
    baseDomain: "portal.dev.local"

Role & Rights (ReBAC with OpenFGA)¶

Platform Mesh implements Relationship-Based Access Control using OpenFGA.

Detailed ReBAC Documentation

For comprehensive information about the authorization system, see:

ReBAC Overview → - Introduction to Relationship-Based Access Control
Authorization Model → - Complete OpenFGA model documentation
Security Operator → - Security operator integration
IAM Service Integration → - Identity and access management
Account Operator Integration → - Account-level authorization

Authorization Model¶

┌─────────────────────────────────────────────────────────────────┐
│                    OpenFGA Authorization                        │
├─────────────────────────────────────────────────────────────────┤
│  User ──[member_of]──► Organization ──[owns]──► Workspace      │
│    │                                               │            │
│    └──[has_role]──► Role ──[grants]──► Permission              │
│                                               │                 │
│                                    ──[on]──► Resource          │
└─────────────────────────────────────────────────────────────────┘

Key Relationships¶

Relationship	Description
`user:X member organization:Y`	User belongs to organization
`user:X admin organization:Y`	User is admin of organization
`organization:Y owner workspace:Z`	Organization owns workspace
`user:X viewer workspace:Z`	User can view workspace
`user:X editor workspace:Z`	User can edit workspace

Configuration¶

Managed by security-operator which: - Creates OpenFGA tuples based on K8s resources - Syncs Keycloak realms with organizations - Maintains consistency between identity and authorization

Aspect	Status	Notes
Registration	Enabled by default	Keycloak self-registration
Email Verification	Required	Mailpit for local dev
Organization Creation	Via Portal	User can onboard new org
Invite Flow	Supported	Email-based invitations
Customization	Medium	Keycloak themes, email templates

Practical Assessment¶

Strengths¶

Enterprise-ready - Keycloak provides robust identity management
Fine-grained authorization - OpenFGA enables complex permission models
Multi-tenancy - Organization-based isolation built-in
Self-service - Users can register and create organizations

Limitations¶

Complexity - Multiple systems to understand (Keycloak, OpenFGA, security-operator)
Customization - Deep changes require understanding all layers
Email dependency - Self-signup requires email infrastructure
Local development - Mailpit needed for testing flows

Configuration Recommendations¶

Scenario	Approach
Disable self-signup	Configure Keycloak realm
Custom registration fields	Keycloak user attributes
Different role model	Modify OpenFGA model via security-operator
SSO integration	Configure Keycloak identity providers
Approval workflow	Custom extension or Keycloak plugin

Operational Assessment¶

Deployment Complexity¶

Component	Replicas	Resources	Dependencies
Portal	1+	512Mi RAM	Keycloak, GraphQL GW
GraphQL Gateway	1+	1.6Gi RAM	KCP, Listener
Extension Manager	1	256Mi RAM	None
Keycloak	1+	1Gi RAM	PostgreSQL
OpenFGA	1+	512Mi RAM	PostgreSQL

Monitoring Requirements¶

Component	Metrics	Logs
Portal	HTTP metrics	Access logs
GraphQL GW	Query latency, errors	Query logs
Extension Manager	Reconcile metrics	Operator logs
Keycloak	Auth metrics	Audit logs
OpenFGA	Check latency	Authorization logs

Maintenance Considerations¶

Task	Frequency	Effort
Security updates	Monthly	Low-Medium
Version upgrades	Quarterly	Medium
Configuration changes	As needed	Low
Extension management	Ongoing	Low
User management	Ongoing	Low

Contributing Assessment¶

Overall Contributing Feasibility¶

Component	Feasibility	Recommended Approach
Portal UI	Medium	Custom MFE extensions
Luigi	Good	Client libraries, plugins
GraphQL Gateway	Limited	Bug fixes only
Extension Manager	Good	New CRD types
User Management	Limited	Configuration only

Recommended Contributing Areas¶

Custom Micro Frontends
Build organization-specific features
Use ContentConfiguration for registration
Any frontend framework supported
Extension Manager CRDs
Add new resource types
Extend validation logic
Standard K8s operator development
Luigi Plugins
Custom navigation handlers
Authentication providers
UI customizations
Documentation & Examples
Reference implementations
Integration guides
Best practices

Recommendations for CAT¶

Operational Strategy

Choose your approach based on requirements and available resources:

Strategy	Effort	Risk	Recommendation
Use as-is	Low	Low	✅ Start here
Configure	Low-Medium	Low	✅ Self-signup, roles
Extend with MFEs	Medium	Low	Custom features
Modify core	High	High	⚠️ Avoid if possible

Customization Priority¶

High Priority - Configure First
Keycloak realm settings
OpenFGA authorization model
Portal feature toggles
Medium Priority - Extend
Custom micro frontend extensions
Additional ContentConfigurations
Luigi navigation customizations
Low Priority - Modify
Core portal changes
GraphQL schema modifications
Framework-level changes

Skills Required¶

Area	Skills	Training Effort
Portal extensions	Angular/React, TypeScript	Medium
Luigi configuration	JavaScript, JSON	Low
K8s operators	Go, controller-runtime	Medium-High
Keycloak	Java (optional), admin UI	Low-Medium
OpenFGA	Authorization modeling	Medium

Conclusion¶

Key Findings

1. Portal is Modular

Extension-based architecture allows customization without core changes

2. Luigi is Stable

Well-maintained framework with good documentation and active community

3. GraphQL Gateway is Specialized

Use as-is, limited customization needed - designed for specific use case

4. User Management is Comprehensive

Keycloak + OpenFGA provide enterprise-grade identity and authorization

5. Self-Signup Works

Configurable, practical for most use cases with email verification

Recommended Approach

Use Platform Mesh Portal with configuration-first approach:

✅ Configure Keycloak for authentication requirements
✅ Use ContentConfiguration for custom micro frontends
✅ Leverage ReBAC model for authorization
✅ Extend via Luigi plugins only if needed
⚠️ Avoid core framework modifications

The portal components are operationally viable for CAT with medium effort for customization and good modularity for extensions.

Next Steps

Ready to dive deeper? Check out the detailed component documentation linked above to learn more about implementation, configuration, and best practices.

Detailed Component Documentation¶

For comprehensive information about each component, refer to the following detailed guides:

In-Depth Documentation

Core Frameworks:

OpenMFP Framework → Complete guide to the Open Micro Frontend Platform including architecture, configuration, and best practices
Luigi Framework → Enterprise micro frontend framework documentation with API reference and integration examples
GraphQL Gateway → Kubernetes GraphQL Gateway guide including GraphQL basics, query examples, and deployment
Extension Manager Operator → Kubernetes controller for managing ContentConfiguration resources and micro frontend lifecycle
Platform Mesh Portal Integration → How Platform Mesh leverages OpenMFP and Luigi to build its Kubernetes-native portal

Authorization:

ReBAC Overview → Introduction to Relationship-Based Access Control
Authorization Model → Complete OpenFGA model documentation and examples

External Resources¶

Official Repositories:

Authentication & Authorization:

Portal & GraphQL Analysis¶

Executive Summary¶

Component Analysis¶

1. OpenMFP Portal¶

Architecture Overview¶

Technology Stack¶

Complexity Assessment¶

Modularity¶

Contributing Potential¶

2. Luigi Microfrontend Framework¶

Architecture Overview¶

Core Concepts¶

Technology Stack¶

Community Health¶

Complexity Assessment¶

Configuration Example¶

Contributing Potential¶

3. Kubernetes GraphQL Gateway¶

Architecture Overview¶

Key Features¶

Configuration (from Helm values)¶

Complexity Assessment¶

Resource Requirements¶

Contributing Potential¶

4. Extension Manager Operator¶

Architecture Overview¶

Custom Resource Definition¶

Complexity Assessment¶

Contributing Potential¶

User Management, Roles & Self-Signup¶

Architecture Overview¶

User Management (Keycloak)¶

Key Features¶

Organization Onboarding Flow¶

Configuration Points¶

Role & Rights (ReBAC with OpenFGA)¶

Authorization Model¶

Key Relationships¶

Configuration¶

Self-Signup Assessment¶

Practical Assessment¶

Strengths¶

Limitations¶

Configuration Recommendations¶

Operational Assessment¶

Deployment Complexity¶

Monitoring Requirements¶

Maintenance Considerations¶

Contributing Assessment¶

Overall Contributing Feasibility¶

Recommended Contributing Areas¶

Recommendations for CAT¶

Customization Priority¶

Skills Required¶

Conclusion¶

Related Documentation¶

Detailed Component Documentation¶

External Resources¶