JavaScript Module Federation meistern: Die Macht von Shared Scope und Dependency Sharing

In der sich schnell entwickelnden Landschaft der Webentwicklung beinhaltet der Aufbau skalierbarer und wartbarer Anwendungen oft die Einführung ausgefeilter Architekturmuster. Unter diesen hat das Konzept der Microfrontends erheblich an Bedeutung gewonnen, da es Teams ermöglicht, Teile einer Anwendung unabhängig voneinander zu entwickeln und bereitzustellen. Das Herzstück der nahtlosen Integration und des effizienten Code-Sharings zwischen diesen unabhängigen Einheiten ist das Webpack's Module Federation Plugin, und eine kritische Komponente seiner Leistungsfähigkeit ist der Shared Scope.

Dieser umfassende Leitfaden befasst sich eingehend mit dem Shared-Scope-Mechanismus innerhalb von JavaScript Module Federation. Wir werden untersuchen, was es ist, warum es für das Dependency Sharing unerlässlich ist, wie es funktioniert und welche praktischen Strategien es für eine effektive Implementierung gibt. Unser Ziel ist es, Entwickler mit dem Wissen auszustatten, diese leistungsstarke Funktion für verbesserte Leistung, reduzierte Bundle-Größen und eine verbesserte Entwicklererfahrung in verschiedenen globalen Entwicklungsteams zu nutzen.

Was ist JavaScript Module Federation?

Bevor wir uns mit dem Shared Scope befassen, ist es wichtig, das grundlegende Konzept von Module Federation zu verstehen. Module Federation, das mit Webpack 5 eingeführt wurde, ist eine Build-Time- und Run-Time-Lösung, die es JavaScript-Anwendungen ermöglicht, Code (wie Bibliotheken, Frameworks oder sogar ganze Komponenten) zwischen separat kompilierten Anwendungen dynamisch auszutauschen. Dies bedeutet, dass Sie mehrere verschiedene Anwendungen (oft als 'Remotes' oder 'Consumer' bezeichnet) haben können, die Code von einer 'Container'- oder 'Host'-Anwendung laden können und umgekehrt.

Die Hauptvorteile von Module Federation sind:

• Code Sharing: Eliminieren Sie redundanten Code über mehrere Anwendungen hinweg, reduzieren Sie die Gesamtgröße der Bundles und verbessern Sie die Ladezeiten.
• Unabhängige Bereitstellung: Teams können verschiedene Teile einer großen Anwendung unabhängig voneinander entwickeln und bereitstellen, was Agilität und schnellere Releasezyklen fördert.
• Technologie-Agnostizismus: Obwohl es hauptsächlich mit Webpack verwendet wird, erleichtert es das Teilen über verschiedene Build-Tools oder Frameworks hinweg bis zu einem gewissen Grad und fördert so die Flexibilität.
• Runtime-Integration: Anwendungen können zur Laufzeit zusammengestellt werden, was dynamische Aktualisierungen und flexible Anwendungsstrukturen ermöglicht.

Das Problem: Redundante Abhängigkeiten in Microfrontends

Stellen Sie sich ein Szenario vor, in dem Sie mehrere Microfrontends haben, die alle von derselben Version einer gängigen UI-Bibliothek wie React oder einer State-Management-Bibliothek wie Redux abhängen. Ohne einen Mechanismus zum Teilen würde jedes Microfrontend seine eigene Kopie dieser Abhängigkeiten bündeln. Dies führt zu:

• Aufgeblähte Bundle-Größen: Jede Anwendung dupliziert unnötigerweise gemeinsame Bibliotheken, was zu größeren Downloadgrößen für die Benutzer führt.
• Erhöhter Speicherverbrauch: Mehrere Instanzen derselben Bibliothek, die im Browser geladen werden, können mehr Speicher verbrauchen.
• Inkonsistentes Verhalten: Unterschiedliche Versionen von gemeinsam genutzten Bibliotheken in verschiedenen Anwendungen können zu subtilen Fehlern und Kompatibilitätsproblemen führen.
• Verschwendete Netzwerkressourcen: Benutzer laden möglicherweise dieselbe Bibliothek mehrmals herunter, wenn sie zwischen verschiedenen Microfrontends navigieren.

Hier kommt der Shared Scope von Module Federation ins Spiel und bietet eine elegante Lösung für diese Herausforderungen.

Shared Scope von Module Federation verstehen

Der Shared Scope, der oft über die Option shared innerhalb des Module Federation Plugins konfiguriert wird, ist der Mechanismus, der es mehreren unabhängig voneinander bereitgestellten Anwendungen ermöglicht, Abhängigkeiten gemeinsam zu nutzen. Wenn Module Federation konfiguriert ist, stellt es sicher, dass eine einzelne Instanz einer angegebenen Abhängigkeit geladen und allen Anwendungen zur Verfügung gestellt wird, die sie benötigen.

Im Kern funktioniert der Shared Scope, indem er eine globale Registry oder einen Container für gemeinsam genutzte Module erstellt. Wenn eine Anwendung eine gemeinsam genutzte Abhängigkeit anfordert, prüft Module Federation diese Registry. Wenn die Abhängigkeit bereits vorhanden ist (d. h. von einer anderen Anwendung oder dem Host geladen wurde), wird diese vorhandene Instanz verwendet. Andernfalls wird die Abhängigkeit geladen und im Shared Scope zur zukünftigen Verwendung registriert.

Die Konfiguration sieht typischerweise wie folgt aus:

            // webpack.config.js

const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ... other webpack configurations
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      remotes: {
        'app1': 'app1@http://localhost:3001/remoteEntry.js',
        'app2': 'app2@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Wichtige Konfigurationsoptionen für Shared Dependencies:

• singleton: true: Dies ist vielleicht die wichtigste Option. Wenn sie auf true gesetzt ist, stellt sie sicher, dass nur eine einzige Instanz der gemeinsam genutzten Abhängigkeit über alle verbrauchenden Anwendungen hinweg geladen wird. Wenn mehrere Anwendungen versuchen, dieselbe Singleton-Abhängigkeit zu laden, stellt Module Federation ihnen dieselbe Instanz zur Verfügung.
• eager: true: Standardmäßig werden gemeinsam genutzte Abhängigkeiten lazy geladen, d. h. sie werden erst abgerufen, wenn sie explizit importiert oder verwendet werden. Wenn Sie eager: true setzen, wird die Abhängigkeit gezwungen, beim Start der Anwendung geladen zu werden, auch wenn sie nicht sofort verwendet wird. Dies kann für kritische Bibliotheken wie Frameworks von Vorteil sein, um sicherzustellen, dass sie von Anfang an verfügbar sind.
• requiredVersion: '...': Diese Option gibt die erforderliche Version der gemeinsam genutzten Abhängigkeit an. Module Federation versucht, die angeforderte Version zu finden. Wenn mehrere Anwendungen unterschiedliche Versionen benötigen, verfügt Module Federation über Mechanismen, um dies zu handhaben (wird später erläutert).
• version: '...': Sie können die Version der Abhängigkeit, die im Shared Scope veröffentlicht wird, explizit festlegen.
• import: false: Diese Einstellung weist Module Federation an, die gemeinsam genutzte Abhängigkeit nicht automatisch zu bündeln. Stattdessen wird erwartet, dass sie extern bereitgestellt wird (was das Standardverhalten beim Teilen ist).
• packageDir: '...': Gibt das Paketverzeichnis an, aus dem die gemeinsam genutzte Abhängigkeit aufgelöst werden soll, was in Monorepos nützlich ist.

Wie Shared Scope Dependency Sharing ermöglicht

Lassen Sie uns den Prozess anhand eines praktischen Beispiels aufschlüsseln. Stellen Sie sich vor, wir haben eine Hauptanwendung 'Container' und zwei 'Remote'-Anwendungen, `app1` und `app2`. Alle drei Anwendungen hängen von `react` und `react-dom` Version 18 ab.

Szenario 1: Container-Anwendung teilt Abhängigkeiten

In diesem gängigen Setup definiert die Container-Anwendung die gemeinsam genutzten Abhängigkeiten. Die von Module Federation generierte Datei `remoteEntry.js` stellt diese gemeinsam genutzten Module zur Verfügung.

Webpack-Konfiguration des Containers (`container/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      filename: 'remoteEntry.js',
      exposes: {
        './App': './src/App',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Nun werden `app1` und `app2` diese gemeinsam genutzten Abhängigkeiten nutzen.

Webpack-Konfiguration von `app1` (`app1/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './Feature1': './src/Feature1',
      },
      remotes: {
        'container': 'container@http://localhost:3000/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Webpack-Konfiguration von `app2` (`app2/webpack.config.js`):

Die Konfiguration für `app2` wäre ähnlich wie bei `app1`, wobei `react` und `react-dom` ebenfalls als Shared mit denselben Versionsanforderungen deklariert werden.

So funktioniert es zur Laufzeit:

1. Die Container-Anwendung wird zuerst geladen, wodurch ihre gemeinsam genutzten `react`- und `react-dom`-Instanzen in ihrem Module-Federation-Scope verfügbar werden.
2. Wenn `app1` geladen wird, fordert es `react` und `react-dom` an. Module Federation in `app1` erkennt, dass diese als Shared und `singleton: true` markiert sind. Es prüft den globalen Scope auf vorhandene Instanzen. Wenn der Container sie bereits geladen hat, verwendet `app1` diese Instanzen wieder.
3. Wenn `app2` geladen wird, verwendet es ebenfalls dieselben `react`- und `react-dom`-Instanzen wieder.

Dies führt dazu, dass nur eine Kopie von `react` und `react-dom` in den Browser geladen wird, wodurch die gesamte Downloadgröße erheblich reduziert wird.

Szenario 2: Sharing von Abhängigkeiten zwischen Remote-Anwendungen

Module Federation ermöglicht es auch Remote-Anwendungen, Abhängigkeiten untereinander zu teilen. Wenn `app1` und `app2` beide eine Bibliothek verwenden, die *nicht* vom Container geteilt wird, können sie sie trotzdem teilen, wenn beide sie in ihren jeweiligen Konfigurationen als Shared deklarieren.

Beispiel: Nehmen wir an, `app1` und `app2` verwenden beide eine Utility-Bibliothek `lodash`.

Webpack-Konfiguration von `app1` (Hinzufügen von Lodash):

            
// ... innerhalb von ModuleFederationPlugin für app1
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

Webpack-Konfiguration von `app2` (Hinzufügen von Lodash):

            
// ... innerhalb von ModuleFederationPlugin für app2
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

In diesem Fall, auch wenn der Container `lodash` nicht explizit teilt, gelingt es `app1` und `app2`, eine einzelne Instanz von `lodash` untereinander zu teilen, vorausgesetzt, sie werden im selben Browserkontext geladen.

Umgang mit Versionskonflikten

Eine der häufigsten Herausforderungen beim Dependency Sharing ist die Versionskompatibilität. Was passiert, wenn `app1` `react` v18.1.0 und `app2` `react` v18.2.0 benötigt? Module Federation bietet robuste Strategien für die Verwaltung dieser Szenarien.

1. Strikte Versionsübereinstimmung (Standardverhalten für `requiredVersion`)

Wenn Sie eine genaue Version (z. B. '18.1.0') oder einen strikten Bereich (z. B. '^18.1.0') angeben, erzwingt Module Federation dies. Wenn eine Anwendung versucht, eine gemeinsam genutzte Abhängigkeit mit einer Version zu laden, die die Anforderung einer anderen Anwendung, die sie bereits verwendet, nicht erfüllt, kann dies zu Fehlern führen.

2. Versionsbereiche und Fallbacks

Die Option requiredVersion unterstützt semantische Versionsbereiche (SemVer). Zum Beispiel bedeutet '^18.0.0' jede Version von 18.0.0 bis zu (aber nicht einschließlich) 19.0.0. Wenn mehrere Anwendungen Versionen innerhalb dieses Bereichs benötigen, verwendet Module Federation typischerweise die höchste kompatible Version, die alle Anforderungen erfüllt.

Betrachten Sie Folgendes:

• Container: shared: { 'react': { requiredVersion: '^18.0.0' } }
• `app1`: shared: { 'react': { requiredVersion: '^18.1.0' } }
• `app2`: shared: { 'react': { requiredVersion: '^18.2.0' } }

Wenn der Container zuerst geladen wird, stellt er `react` v18.0.0 (oder welche Version er tatsächlich bündelt) bereit. Wenn `app1` `react` mit `^18.1.0` anfordert, kann dies fehlschlagen, wenn die Version des Containers niedriger als 18.1.0 ist. Wenn jedoch `app1` zuerst geladen wird und `react` v18.1.0 bereitstellt und dann `app2` `react` mit `^18.2.0` anfordert, versucht Module Federation, die Anforderung von `app2` zu erfüllen. Wenn die `react` v18.1.0-Instanz bereits geladen ist, kann sie einen Fehler auslösen, da v18.1.0 nicht `^18.2.0` erfüllt.

Um dies zu vermeiden, empfiehlt es sich, gemeinsam genutzte Abhängigkeiten mit dem weitesten akzeptablen Versionsbereich zu definieren, normalerweise in der Container-Anwendung. Zum Beispiel ermöglicht die Verwendung von '^18.0.0' Flexibilität. Wenn eine bestimmte Remote-Anwendung eine harte Abhängigkeit von einer neueren Patch-Version hat, sollte sie so konfiguriert werden, dass sie diese Version explizit bereitstellt.

3. Verwendung von `shareKey` und `shareScope`

Module Federation ermöglicht es Ihnen auch, den Schlüssel zu steuern, unter dem ein Modul freigegeben wird, und den Scope, in dem es sich befindet. Dies kann für fortgeschrittene Szenarien nützlich sein, z. B. zum Freigeben verschiedener Versionen derselben Bibliothek unter verschiedenen Schlüsseln.

4. Die Option `strictVersion`

Wenn strictVersion aktiviert ist (was der Standardwert für requiredVersion ist), löst Module Federation einen Fehler aus, wenn eine Abhängigkeit nicht erfüllt werden kann. Wenn Sie strictVersion: false festlegen, können Sie eine nachsichtigere Versionsbehandlung ermöglichen, bei der Module Federation möglicherweise versucht, eine ältere Version zu verwenden, wenn keine neuere verfügbar ist, was jedoch zu Laufzeitfehlern führen kann.

Best Practices für die Verwendung von Shared Scope

Um den Shared Scope von Module Federation effektiv zu nutzen und häufige Fallstricke zu vermeiden, sollten Sie diese Best Practices berücksichtigen:

1. Zentralisieren Sie gemeinsam genutzte Abhängigkeiten: Bestimmen Sie eine primäre Anwendung (oft den Container oder eine dedizierte Shared-Library-Anwendung) als Quelle der Wahrheit für gängige, stabile Abhängigkeiten wie Frameworks (React, Vue, Angular), UI-Komponentenbibliotheken und State-Management-Bibliotheken.
2. Definieren Sie breite Versionsbereiche: Verwenden Sie SemVer-Bereiche (z. B. '^18.0.0') für gemeinsam genutzte Abhängigkeiten in der primären Sharing-Anwendung. Dies ermöglicht es anderen Anwendungen, kompatible Versionen zu verwenden, ohne strenge Aktualisierungen im gesamten Ökosystem zu erzwingen.
3. Dokumentieren Sie gemeinsam genutzte Abhängigkeiten klar: Führen Sie eine klare Dokumentation darüber, welche Abhängigkeiten gemeinsam genutzt werden, welche Versionen sie haben und welche Anwendungen für deren Freigabe verantwortlich sind. Dies hilft Teams, den Abhängigkeitsgraphen zu verstehen.
4. Überwachen Sie Bundle-Größen: Analysieren Sie regelmäßig die Bundle-Größen Ihrer Anwendungen. Der Shared Scope von Module Federation sollte zu einer Verringerung der Größe dynamisch geladener Chunks führen, da gängige Abhängigkeiten externalisiert werden.
5. Verwalten Sie nicht-deterministische Abhängigkeiten: Seien Sie vorsichtig bei Abhängigkeiten, die häufig aktualisiert werden oder instabile APIs haben. Das Teilen solcher Abhängigkeiten erfordert möglicherweise eine sorgfältigere Versionsverwaltung und Tests.
6. Verwenden Sie eager: true mit Bedacht: Während eager: true sicherstellt, dass eine Abhängigkeit frühzeitig geladen wird, kann eine übermäßige Verwendung zu größeren anfänglichen Ladezeiten führen. Verwenden Sie es für kritische Bibliotheken, die für den Start der Anwendung unerlässlich sind.
7. Testen ist entscheidend: Testen Sie die Integration Ihrer Microfrontends gründlich. Stellen Sie sicher, dass gemeinsam genutzte Abhängigkeiten korrekt geladen werden und dass Versionskonflikte ordnungsgemäß behandelt werden. Automatisierte Tests, einschließlich Integrations- und End-to-End-Tests, sind unerlässlich.
8. Erwägen Sie Monorepos zur Vereinfachung: Für Teams, die mit Module Federation beginnen, kann die Verwaltung gemeinsam genutzter Abhängigkeiten innerhalb eines Monorepos (mithilfe von Tools wie Lerna oder Yarn Workspaces) die Einrichtung vereinfachen und Konsistenz gewährleisten. Die Option `packageDir` ist hier besonders nützlich.
9. Behandeln Sie Edge Cases mit `shareKey` und `shareScope`: Wenn Sie auf komplexe Versionierungsszenarien stoßen oder verschiedene Versionen derselben Bibliothek bereitstellen müssen, erkunden Sie die Optionen `shareKey` und `shareScope` für eine detailliertere Kontrolle.
10. Sicherheitsüberlegungen: Stellen Sie sicher, dass gemeinsam genutzte Abhängigkeiten von vertrauenswürdigen Quellen abgerufen werden. Implementieren Sie Sicherheitsbest Practices für Ihre Build-Pipeline und Ihren Bereitstellungsprozess.

Globale Auswirkungen und Überlegungen

Für globale Entwicklungsteams bieten Module Federation und sein Shared Scope erhebliche Vorteile:

• Konsistenz über Regionen hinweg: Stellt sicher, dass alle Benutzer, unabhängig von ihrem geografischen Standort, die Anwendung mit denselben Kernabhängigkeiten erleben, wodurch regionale Inkonsistenzen reduziert werden.
• Schnellere Iterationszyklen: Teams in verschiedenen Zeitzonen können an unabhängigen Funktionen oder Microfrontends arbeiten, ohne sich ständig Sorgen machen zu müssen, gängige Bibliotheken zu duplizieren oder sich gegenseitig in Bezug auf Abhängigkeitsversionen auf die Füße zu treten.
• Optimiert für verschiedene Netzwerke: Das Reduzieren der Gesamt-Downloadgröße durch gemeinsam genutzte Abhängigkeiten ist besonders vorteilhaft für Benutzer mit langsameren oder getakteten Internetverbindungen, die in vielen Teilen der Welt vorherrschen.
• Vereinfachtes Onboarding: Neue Entwickler, die einem großen Projekt beitreten, können die Anwendungsarchitektur und das Abhängigkeitsmanagement leichter verstehen, wenn gängige Bibliotheken klar definiert und gemeinsam genutzt werden.

Globale Teams müssen jedoch auch Folgendes berücksichtigen:

• CDN-Strategien: Wenn gemeinsam genutzte Abhängigkeiten auf einem CDN gehostet werden, stellen Sie sicher, dass das CDN eine gute globale Reichweite und geringe Latenz für alle Zielregionen aufweist.
• Offline-Unterstützung: Für Anwendungen, die Offline-Funktionen benötigen, wird die Verwaltung gemeinsam genutzter Abhängigkeiten und deren Caching komplexer.
• Einhaltung gesetzlicher Vorschriften: Stellen Sie sicher, dass die Freigabe von Bibliotheken allen relevanten Softwarelizenzierungs- oder Datenschutzbestimmungen in verschiedenen Gerichtsbarkeiten entspricht.

Häufige Fallstricke und wie man sie vermeidet

1. Falsch konfigurierter `singleton`

Problem: Vergessen, singleton: true für Bibliotheken festzulegen, die nur eine Instanz haben sollten.

Lösung: Legen Sie immer singleton: true für Frameworks, Bibliotheken und Dienstprogramme fest, die Sie eindeutig in Ihren Anwendungen freigeben möchten.

2. Inkonsistente Versionsanforderungen

Problem: Verschiedene Anwendungen geben sehr unterschiedliche, inkompatible Versionsbereiche für dieselbe gemeinsam genutzte Abhängigkeit an.

Lösung: Standardisieren Sie Versionsanforderungen, insbesondere in der Container-App. Verwenden Sie breite SemVer-Bereiche und dokumentieren Sie alle Ausnahmen.

3. Übermäßiges Teilen nicht essenzieller Bibliotheken

Problem: Der Versuch, jede einzelne kleine Utility-Bibliothek freizugeben, was zu einer komplexen Konfiguration und potenziellen Konflikten führt.

Lösung: Konzentrieren Sie sich auf das Teilen großer, gängiger und stabiler Abhängigkeiten. Kleine, selten verwendete Dienstprogramme lassen sich möglicherweise besser lokal bündeln, um Komplexität zu vermeiden.

4. Die Datei `remoteEntry.js` wird nicht korrekt behandelt

Problem: Die Datei `remoteEntry.js` ist für verbrauchende Anwendungen nicht zugänglich oder wird nicht korrekt bereitgestellt.

Lösung: Stellen Sie sicher, dass Ihre Hosting-Strategie für Remote-Einträge robust ist und dass die in der Konfiguration `remotes` angegebenen URLs korrekt und zugänglich sind.

5. Implikationen von `eager: true` ignorieren

Problem: Zu viele Abhängigkeiten auf eager: true setzen, was zu einer langsamen anfänglichen Ladezeit führt.

Lösung: Verwenden Sie eager: true nur für Abhängigkeiten, die für das anfängliche Rendering oder die Kernfunktionalität Ihrer Anwendungen unbedingt erforderlich sind.

Fazit

Der Shared Scope von JavaScript Module Federation ist ein leistungsstarkes Werkzeug zum Erstellen moderner, skalierbarer Webanwendungen, insbesondere innerhalb einer Microfrontend-Architektur. Durch die Ermöglichung des effizienten Dependency Sharings werden Probleme mit Codeduplizierung, Bloat und Inkonsistenz angegangen, was zu verbesserter Leistung und Wartbarkeit führt. Das Verstehen und korrekte Konfigurieren der Option shared, insbesondere der Eigenschaften singleton und requiredVersion, ist der Schlüssel zur Erschließung dieser Vorteile.

Da globale Entwicklungsteams zunehmend Microfrontend-Strategien übernehmen, wird die Beherrschung des Shared Scopes von Module Federation von größter Bedeutung. Indem Sie sich an Best Practices halten, die Versionierung sorgfältig verwalten und gründliche Tests durchführen, können Sie diese Technologie nutzen, um robuste, leistungsstarke und wartbare Anwendungen zu erstellen, die eine vielfältige internationale Benutzerbasis effektiv bedienen.

Nutzen Sie die Macht des Shared Scopes und ebnen Sie den Weg für eine effizientere und kollaborativere Webentwicklung in Ihrem Unternehmen.