Evaluierung Plattform-Rahmen Integrations Ansätze
Einleitung
Es soll eine Bewertung von Plattform-Rahmen Optionen / Empfehlungen vorgenommen werden, um verschiedene Micro-Frontends (in Form von Data Apps für Use-Cases) in einer visuellen Plattform zu integrieren.
Falls die Plattform einen Portal-Rahmen als "Hülle" um Use-Cases zur Verfügung stellen soll, muss versucht werden, diesen nicht komplett "from scratch" zu entwickeln. Hintergrund ist die erhebliche Komplexität die in diesen Querschnittsfunktionen enthalten ist. Daher muss möglichst auf existierende Funktionalität eines Frameworks aufgebaut werden, folgend werden mehrere bewertet.
Wichtigste Kern-Funktionen sind:
- Handling der Authentifizierung für die Use-Cases
- Registrierung der Use-Cases
- Absprung in die Use-Cases
- Integration der Use-Cases in den Rahmen
- UI Rahmen (übergreifende Navigation, Header, Footer mit Service-Links)
Vordergründig ist dabei die Integration von Use-Cases als MicroFrontends unter einer gemeinsamen Hülle zur Laufzeit angestrebt, die möglichst frei in der Auswahl der Implementierung bleibt.
Explizit nicht im Fokus sind Themen wie Auslagerung von gemeinsam benutzten Bibliotheken oder auch Module Federation. Ebenso nicht aufgeführt sind Backend-Integrationsansätze wie z.B. JSR-286, da hier betrieblich ein bedeutender Overhead entsteht und zu starke Einschränkung der Technologie (Java) statt finden würde.
Optionen
Im Folgenden werden relevante Optionen betrachtet.
Custom-Lösungen basierend auf JS/TS-Frameworks:
Nicht betrachtet:
- Podium.io (nicht aktiv maintained, zu starke Kopplung an podium framework in Use-Case Implementierung )
Evaluierung
| Anforderung | Mashroom Server | Piral | micro-lc | Scion |
|---|---|---|---|---|
| Framework-agnostisch | ja | nein (bis hin zu bundler) | ja | ja |
| Authentifizierung gegen OAuth/OIDC | ja | ja (3rd party) | nein | nein |
| Weitergabe Authentifizierung an Use-Case | ja (API Proxy) | custom | custom | custom |
| Registrierung von Use-Cases in die Plattform | ja (konfigurativ/discovery) | ja (Pilet Feed) | ja (konfigurativ) | ja (konfigurativ) |
| zentrale Navigation zwischen Use-Cases | ja | ja | ja | custom |
| Einschränkung auf Use-Cases via RBAC Konfiguration | ja | nein | nein | nein |
| einheitlicher gebrandeter UI Rahmen | anpassbar (Themes) | custom | ja (custom) | custom |
| Integration der Anwendungen | Frontend & Server side (Express) | Frontend | Frontend | Frontend |
| Kommunikation Plattform/Use-Cases möglich | Frontend Message Bus | custom | ja | Frontend Message Broker |
| zentrales Error-Handling | ja | nein | nein | nein |
| Cross-Domain Aspekte berücksichtigt | ja (API Proxy) | nein | nein | nur Messaging |
| Lizenz | MIT | MIT (nicht piral.cloud) | Apache 2.0 | Eclipse Public License 2.0 |
| Monitoring | Prometheus, PM2 | nein | nein | nein |
| Aktivität Entwicklung | seit 2024 mittel | nach 2022 niedrig | nach 2023 niedrig | kontinuierlich niedrig |
| Github Stars | 57 | 1800 | 221 | 71 |
| Dokumentation | mittel | umfangreich | mittel | umfangreich |
Empfehlung
Am geeignetsten für das Vorhaben der Datenfabrik erscheint aktuell mashroom-server, da das Framework folgende Vorteile mitbringt:
- keine Festlegung auf ein Frontend-Framework
- weitreichende Ansätze für Authentifizierung und rollenbasierte Zugriffe auf Microfrontends schon implementiert
- auch Authentifizierung als OIDC Confidential Client mit serverseitigen Sessions möglich
- Cross-Domain Proxying ist enthalten
- Vorbereitung auf Betrieb in Kubernetes schon enthalten inkl. automatischer Discovery von Microfrontends wenn gewünscht
Ein Nachteil des Frameworks ist allerdings, dass die Entwickler-Community dahinter relativ klein ist. Durch die MIT Lizenz könnte im Fall, dass keine Weiterentwicklung mehr statt findet, diese aber im Rahmen eines Forks erfolgen.
Weitere Beobachtungen:
- das "Scoping" von Frontend-Styles liegt in der Verantwortung der einzelnen Microfrontends, d.h. es muss darauf geachtet werden keine Styles der Plattform zu überschreiben und nur spezifische Definitionen vorzunehmen. Falls globale Themes genutzt werden sollen, muss auch dies berücksichtigt werden.
- bei der Entwicklung von Microfrontends müssen zumindest einige wenige Vorgaben seitens Mashroom beachtet werden, damit diese später in dem Plattformrahmen laufen können. Eine vollkommen entkoppelte Entwicklung funktioniert nur bei einer iFrame-Integration.
Notwendige Arbeiten für Benutzung innerhalb der Datenfabrik
Es ist zu prüfen ob notwendige Anpassungen des Portalrahmens v.a. im Hinblick auf UX/UI im aktuellen Projekt erfolgen. Eine Verprobung mit generischem UX/UI ist sicherlich unproblematisch, dies ergibt aber keinen Rahmen welcher als Grundlage von später zu entwickelnden Data Apps direkt einsetzbar ist. Es fehlen:
- UX/UI Konzept (Navigation, Header, Footer, Branding)
- Implementierung des daraus folgenden Frontend Theme und Bereitstellung für perspektivische Data Appps
- Guidelines für Entwicklung von Data Apps für den Portalrahmen (v.a. im Hinblick auf eigenes Styling, Zugriff auf Authentifizierungsfunktionen)
Generelle Herausforderungen
Bei allen Vorteilen die ein Portalrahmen bietet, bringt er aber auch Nachteile mit sich, die gegenüber den Projektzielen abzuwägen sind.
- Schaffung organisatorischer und operativer Strukturen (Support & Maintenance Portalrahmen, Onboarding neuer Microfrontends, Governance um unkontrollierte Entwicklungen zu minimieren und Wiederverwendung zu maximieren)
- Gemeinsame Verwendung von UX sowie UI Styles führen zu Abhängigkeiten / Kopplung zwischen Teams
- Navigation/Routing via Browser-URLs ist im Portal-Rahmen nur begrenzt einsetzbar