WEBVTT

00:00:00.017 --> 00:00:02.877
Mach doch mal den Elevator-Quiz. Was ist Module-Federation? Welches Problem löst mir das?

00:00:03.097 --> 00:00:08.617
Ganz kurz gesagt kann man damit aus anderen Anwendungen, aus separat kompilierten

00:00:08.617 --> 00:00:10.537
Anwendungen etwas laden.

00:00:10.877 --> 00:00:14.137
Und verwenden tut man es für Laufzeit-Integration.

00:00:15.037 --> 00:00:18.657
Der Benutzer hat das Gefühl, mit einer Anwendung zu arbeiten,

00:00:18.837 --> 00:00:20.397
bekommt genau das, was er braucht.

00:00:20.657 --> 00:00:24.917
In Wirklichkeit hat man viele, viele kleine Anwendungen, die von kleineren,

00:00:24.917 --> 00:00:29.977
schlagfertigen Teams entwickelt werden. Und die können eben rasch,

00:00:29.977 --> 00:00:32.217
agil Geschäftsnutzen liefern.

00:00:33.040 --> 00:00:58.000
Music.

00:00:57.817 --> 00:00:59.937
Working Draft Revision 627,

00:01:02.977 --> 00:01:06.297
Diese Revision von Working Draft wird euch präsentiert von Mitwald.

00:01:06.437 --> 00:01:08.417
Next Level Hosting für deine Projekte.

00:01:08.637 --> 00:01:11.837
Jetzt fragt ihr euch bestimmt, wie kann sowas langweiliges wie Hosting Next

00:01:11.837 --> 00:01:13.377
Level sein? Ganz einfach.

00:01:13.937 --> 00:01:17.577
Mitwalds hochperformantes Cloud Hosting ist perfekt abgestimmt auf die Anforderungen

00:01:17.577 --> 00:01:19.097
von Freelancern und Agenturen.

00:01:19.257 --> 00:01:22.697
Es gibt zum Beispiel ein smartes Rollensystem für die Zusammenarbeit mit euren

00:01:22.697 --> 00:01:27.077
Projektpartnern und Midwald hat mit M-Studio auch eine sehr schöne moderne Verwaltungsoberfläche

00:01:27.077 --> 00:01:28.797
gebaut, mit der das Arbeiten Spaß macht.

00:01:28.917 --> 00:01:33.337
Aber jetzt mal ehrlich unter uns Nerds. Sachen anklicken? In einem User-Interface?

00:01:33.457 --> 00:01:35.557
Muss das sein? Nein, muss es nicht.

00:01:35.717 --> 00:01:39.657
Denn bei Midwald gibt's die M-Studio CLI. Mit der könnt ihr euer Hosting komplett

00:01:39.657 --> 00:01:42.897
über die Kommandozeile verwalten und natürlich auch entsprechend automatisieren.

00:01:43.057 --> 00:01:46.637
Von Nerds für Nerds bringt euch Midwald die optimale Developer-Experience,

00:01:46.677 --> 00:01:47.717
wenn's ums Hosting geht.

00:01:47.857 --> 00:01:53.217
Und deshalb jetzt auf zu midwald.de slash workingdraft. Denn da wartet auf euch

00:01:53.217 --> 00:01:57.597
exklusiv als Hörer von Working Draft, das Angebot, den Tarif pro Space für 30

00:01:57.597 --> 00:01:58.997
Tage kostenlos zu nutzen.

00:01:59.097 --> 00:02:02.437
Das war nochmal mittwald.de.

00:02:03.777 --> 00:02:07.657
Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft.

00:02:11.304 --> 00:02:14.384
Hallo und herzlich willkommen zu Working Draft Revision 627.

00:02:14.804 --> 00:02:17.384
Heute bin ich am Start, der Peter, aber ich habe einen hoch,

00:02:17.404 --> 00:02:20.484
hoch, hoch, hochkarätigen Gast an Bord, nämlich den Manfred.

00:02:20.644 --> 00:02:22.564
Moin Manfred. Hallo, servus.

00:02:23.384 --> 00:02:27.584
Manfred, es ist jetzt ja leider so, da draußen laufen noch andere Frameworks

00:02:27.584 --> 00:02:29.524
freilaufend rum, die nicht Angular sind.

00:02:29.804 --> 00:02:32.804
Das heißt, wir müssen davon ausgehen, dass einige von unseren Hörern noch nie

00:02:32.804 --> 00:02:33.624
was von dir gehört haben.

00:02:34.384 --> 00:02:36.764
Kannst du das mal kurz reparieren? Ja, genau. Das habe ich auch schon gehört,

00:02:36.884 --> 00:02:38.724
dass es auch andere Frameworks gibt.

00:02:38.924 --> 00:02:41.984
Ja, leider. Aber du weißt doch, von mir aus können ja die Frameworks überleben,

00:02:42.044 --> 00:02:43.644
solange alle Bescheid wissen, wer du bist.

00:02:43.844 --> 00:02:46.084
Deswegen, kannst du mal kurz erzählen, wer du bist, was du machst?

00:02:46.964 --> 00:02:51.464
Ja, sehr gerne. Also ich bin der Manfred Steyer. Ich bin Trainer und Berater

00:02:51.464 --> 00:02:55.804
für Angola und fokussiere mich auf Angola im Enterprise-Umfeld.

00:02:55.804 --> 00:03:02.244
Und in der Rolle mache ich ganz viele Beratungen und Trainings und reise quasi

00:03:02.244 --> 00:03:06.324
durch den deutschen Sprachraum, komme eigentlich aus Österreich,

00:03:06.464 --> 00:03:09.764
das hört man auch, aber ich bin sehr mit Deutschland verbunden.

00:03:09.864 --> 00:03:14.204
Ich bin im Schnitt jede zweite Woche in Deutschland, reise durch die Bundesländer

00:03:14.204 --> 00:03:18.804
und helfe da eben Firmen mit Angular im Enterprise-Umfeld. Ja,

00:03:18.824 --> 00:03:22.284
und daneben bin ich auch ganz gut mit der Angular-Community verknüpft.

00:03:22.304 --> 00:03:29.244
Bin zum Beispiel GDE für Angular und habe auch über Angular bei Aureli geschrieben. Was ist denn ein GDE?

00:03:30.064 --> 00:03:35.924
Ein GDE ist ein Google Developer Expert. Das ist jemand, der für Google-Technologien

00:03:35.924 --> 00:03:37.904
viel Öffentlichkeitsarbeit macht.

00:03:38.104 --> 00:03:40.104
In meinem Fall war es halt Angular.

00:03:40.724 --> 00:03:45.424
Okay. Angular Architects.io ist die, glaube ich, zu nennende Webseite noch,

00:03:45.504 --> 00:03:47.184
wenn man dich und deine Kollegen anhören möchte.

00:03:47.704 --> 00:03:51.184
Ja, genau. Das ist unsere Gruppe, unsere Firma.

00:03:51.604 --> 00:03:56.124
Und ja, genau, da kann man dann Schulungen, Trainings, Beratungen, Reviews buchen.

00:03:57.344 --> 00:04:01.704
Ja, und du hast es ja im Prinzip schon gesagt, du bist ja Teil dieses ganzen

00:04:01.704 --> 00:04:06.184
amorphen Wanderzirkus, der sich auf den diversen Konferenzen immer so manifestiert.

00:04:07.784 --> 00:04:10.344
Also ich vermute mal, wir beide haben irgendwie Familienmitglieder,

00:04:10.404 --> 00:04:12.864
die wir weniger häufig sehen, als dass wir uns sehen.

00:04:14.104 --> 00:04:18.564
Genau, genau. Und das aber auch ganz bewusst. Jedem muss man nicht immer helfen.

00:04:42.864 --> 00:04:45.664
Mitgearbeitet. abgeschnitten, was das will, was das soll, was das kann und was

00:04:45.664 --> 00:04:48.064
da so an Ideen dran ist, die man sich eventuell auch klauen kann,

00:04:48.164 --> 00:04:50.904
wenn man irgendwer von diesen heretischen Non-Angular-Leuten ist.

00:04:51.404 --> 00:04:54.164
Und deswegen habe ich dich, glaube ich, mal einfach so kurzerhand beim Frühstück,

00:04:54.164 --> 00:04:58.284
als du noch nicht abwehrfähig warst, für den Podcast hier eingetütet. Ja, genau.

00:04:58.584 --> 00:05:01.484
Und deswegen quatschen wir jetzt einfach mal über Module Federation.

00:05:02.304 --> 00:05:04.324
Mach doch mal den Elevator-Pitch. Was ist Module Federation?

00:05:04.484 --> 00:05:05.404
Welches Problem löst mir das?

00:05:06.629 --> 00:05:10.809
Also ganz kurz gesagt kann man damit aus anderen Anwendungen,

00:05:10.809 --> 00:05:16.889
aus separat kompilierten Anwendungen etwas laden und verwenden tut man es für

00:05:16.889 --> 00:05:18.189
Laufzeit-Integration,

00:05:18.369 --> 00:05:24.189
wo ich zur Laufzeit etwas aus einer ganz anderen Anwendung in meine Anwendung laden möchte.

00:05:24.189 --> 00:05:27.889
Das sind typische Beispiele Plug-in-Architekturen.

00:05:28.209 --> 00:05:33.049
Aber, und darum geht es in den meisten Fällen, da geht es auch um Micro-Frontends.

00:05:33.229 --> 00:05:38.269
Also ich habe ein riesengroßes System, eine riesengroße Enterprise-Anwendung.

00:05:38.289 --> 00:05:44.409
Ich untergliedere die in kleinere lauffähige Anwendungen, die von verschiedenen

00:05:44.409 --> 00:05:45.689
Teams entwickelt werden.

00:05:45.689 --> 00:05:50.829
Und irgendwann will man ja trotzdem den Eindruck einer großen Anwendung haben

00:05:50.829 --> 00:05:55.369
und deswegen muss man dann zur Laufzeit die Routen und die Komponenten aus diesen

00:05:55.369 --> 00:05:58.549
Anwendungen in eine Hauptanwendung integrieren.

00:05:59.389 --> 00:06:02.889
Das heißt, der Benutzer hat das Gefühl, mit einer Anwendung zu arbeiten,

00:06:03.089 --> 00:06:06.589
bekommt genau das, was er braucht, wahrscheinlich sogar ein wenig mehr.

00:06:06.709 --> 00:06:11.009
In Wirklichkeit hat man viele, viele kleine Anwendungen, die von kleineren,

00:06:11.009 --> 00:06:16.089
schlagfertigen Teams entwickelt werden. Die sind einigermaßen autark und die

00:06:16.089 --> 00:06:20.069
können eben rasch, agil Geschäftsnutzen liefern.

00:06:20.829 --> 00:06:25.489
Also so die Idee des Microservice auf das Frontend übertragen. Ja, genau.

00:06:26.449 --> 00:06:30.469
Okay, aber wenn du jetzt so sagst, dann kann ich mir da unter,

00:06:30.529 --> 00:06:35.529
ich habe diese verschiedenen Microfrontends und da können sich A und B gegenseitig

00:06:35.529 --> 00:06:38.069
Funktionalität reinladen, unter anderem auch aus dem Modul C.

00:06:38.069 --> 00:06:41.389
Da wäre ich jetzt ja mal ganz ketzerisch am Start und würde sagen,

00:06:41.609 --> 00:06:46.709
aha, das sind doch Module, also so ECMAScript, Import, so und so,

00:06:46.729 --> 00:06:48.689
from so und so, das gibt es doch schon. Ja, genau.

00:06:49.929 --> 00:06:53.309
Das gibt es mittlerweile schon und davor haben wir Require gehabt.

00:06:53.689 --> 00:06:58.769
Das Problem ist halt nur, dass die meisten kleinseitigen Anwendungen gebandelt

00:06:58.769 --> 00:07:04.069
werden und im Rahmen des Bundlings werden so ziemlich alle Importe aufgelöst

00:07:04.069 --> 00:07:07.969
und da wird dann Lazy Loading gemacht und tot und teufel.

00:07:08.069 --> 00:07:14.049
Und die Konsequenz daraus ist, dass eigentlich alles, was importiert wird mit

00:07:14.049 --> 00:07:19.609
dynamischen Imports, zur Laufzeit, nein nicht zur Laufzeit, zur Compile-Zeit bekannt sein muss.

00:07:19.929 --> 00:07:25.829
Weil es wird ja gemeinsam gebundelt und optimiert und dot und dot for tree shaking und so weiter.

00:07:26.169 --> 00:07:31.089
Wenn wir allerdings jetzt eine Laufzeit-Integration machen, dann laden wir ja

00:07:31.089 --> 00:07:35.349
was zur Laufzeit, das wir so noch nicht zur Compile-Time gekannt haben.

00:07:35.349 --> 00:07:41.249
Weil das Ding wird ja von einem anderen Team entwickelt und irgendwann deployt, wenn die fertig sind.

00:07:41.369 --> 00:07:45.429
Und wenn die eine neue Version haben, dann deployen die einfach die neue Version.

00:07:45.569 --> 00:07:49.349
Das heißt, ich weiß gar nicht ganz genau, was ich da zur Laufzeit reinkriege.

00:07:49.549 --> 00:07:51.209
Okay, also tatsächlich zur Laufzeit

00:07:51.209 --> 00:07:55.549
und mit wirklich komplett voneinander isolierten Microfrontend-Silos.

00:07:57.087 --> 00:08:00.947
Die gegebenenfalls nicht mehr voneinander wissen, als es gibt da irgendwie einen API-Kontrakt.

00:08:00.987 --> 00:08:05.987
Ich kann mir Funktionalität A reinladen, aber es ist jetzt sozusagen nicht dem

00:08:05.987 --> 00:08:07.467
Bundler notwendigerweise bekannt.

00:08:08.107 --> 00:08:13.807
Ja, genau so ist es. Und was dazu kommt, ist, ich will ja auch Abhängigkeiten teilen.

00:08:13.987 --> 00:08:19.687
Ich will ja nicht dreimal Angular herunterladen, nur weil drei Microfrontends

00:08:19.687 --> 00:08:24.587
die gleiche Angular-Version nutzen oder dreimal React, Svelte oder was auch immer.

00:08:24.587 --> 00:08:30.387
Das heißt, ich möchte gerne, wenn mehrere Systemteile die gleiche Abhängigkeit

00:08:30.387 --> 00:08:35.387
in der gleichen Version haben oder zumindest in einer zueinander kompatiblen

00:08:35.387 --> 00:08:38.687
Version, dann will ich das Zeug nur einmal laden und teilen.

00:08:38.847 --> 00:08:41.807
Und das kann Federation auch ganz gut. Okay.

00:08:42.087 --> 00:08:45.187
Das heißt, das wäre, also wenn ich jetzt Module-Federation dann wirklich von

00:08:45.187 --> 00:08:48.727
den normalen Modulen abgrenze, ist es ja eigentlich so, wenn man die normalen

00:08:48.727 --> 00:08:52.707
Module so nehme, wie sie sind und man würde verzichten auf irgendwelche Build-Tools

00:08:52.707 --> 00:08:55.287
und Bundler, dann hätte man das Problem,

00:08:55.487 --> 00:08:59.007
dass die Module-Federation löst, ja eigentlich auch gar nicht.

00:08:59.007 --> 00:09:01.887
Weil der Browser würde ja, wenn man es rein kleinzeitig machen würde,

00:09:02.307 --> 00:09:05.387
diese Dependency Resolution und das ich lade es nur einmal, wenn es sich zwei

00:09:05.387 --> 00:09:07.387
teilen können, ja auch machen.

00:09:08.507 --> 00:09:12.087
Und das wird sozusagen ja erst durch die Bundler tatsächlich notwendig,

00:09:12.087 --> 00:09:13.827
dass man das löst. Verstehe ich das richtig?

00:09:14.627 --> 00:09:16.527
Ja, genau so ist es. Okay.

00:09:17.987 --> 00:09:20.267
Kann man nicht die Bundler dann einfach in die Tonne treten?

00:09:21.567 --> 00:09:23.627
Ja, das würden ja viele Leute gerne machen,

00:09:23.807 --> 00:09:27.987
aber aus Performance-Gründen klappt das dann doch nicht, weil ich halt dann

00:09:27.987 --> 00:09:33.667
gleich in dieser Wasserfall-Problematik drinnen bin, wo ich tausend Files herunterlade.

00:09:34.167 --> 00:09:36.607
Aber ist das nicht irgendwie, also ich bin jetzt leider nicht der Performance-Papst,

00:09:36.607 --> 00:09:39.267
ich wünsche der Chef wäre hier, aber der hängt ja wie gesagt in Venedig rum.

00:09:40.827 --> 00:09:44.307
Aber ist das nicht mit modernen HTTP-Standards gar nicht mehr so das Problem?

00:09:45.287 --> 00:09:52.107
Ja, das sollte man meinen, weil HTTP2 und aufwärts haben da ja Mechanismen eingebaut,

00:09:52.147 --> 00:09:56.387
sowas wie mal proaktiv weitere Files runterschicken zum Browser.

00:09:56.767 --> 00:10:00.487
Allerdings ist das alles nicht ganz so einfach zu konfigurieren.

00:10:00.527 --> 00:10:03.687
Also irgendwie braucht ja das Backend dann Kenntnis darüber,

00:10:03.907 --> 00:10:06.627
was du als nächstes benötigst und so weiter.

00:10:06.627 --> 00:10:11.147
Und da hat man festgestellt, das hat man unter anderem bei Google gemacht,

00:10:11.307 --> 00:10:15.287
diese Untersuchung, dass es trotzdem nach wie vor Vorteile bringt,

00:10:15.527 --> 00:10:17.707
wenn man die Sachen behandelt.

00:10:18.147 --> 00:10:22.387
Ja, okay. Aber du kannst es nicht irgendwie quantifizieren oder so.

00:10:22.567 --> 00:10:25.347
Wie gesagt, du könntest ja von der Parallelität von den modernen HTTP-Standards

00:10:25.347 --> 00:10:29.047
profitieren. Du würdest die ganzen Payloads, die du rüberschickst, ja am Ende eh zippen.

00:10:29.127 --> 00:10:32.387
Das heißt, den ganzen Whitespace rauszuwerfen bringt jetzt nicht so wahnsinnig

00:10:32.387 --> 00:10:35.687
viel oder die Variablen-Namen kurz zu machen bringt nicht so wahnsinnig viel.

00:10:36.886 --> 00:10:40.866
Es ist nicht nichts, aber wie gesagt, ich stecke ja nicht drin und ich weiß

00:10:40.866 --> 00:10:44.266
ja, was Angular für ein Tool ist und dass da natürlich mehr passiert,

00:10:44.326 --> 00:10:46.606
als jetzt einfach nur so die Webpack-Basis-Konfiguration.

00:10:46.886 --> 00:10:49.686
Das ist allen klar, aber jetzt, wie gesagt, aus meiner Perspektive,

00:10:49.686 --> 00:10:52.166
der Person, die sich vielleicht gerne Ideen klauen würde.

00:10:53.706 --> 00:10:55.106
Wenn ich in einer Welt leben würde,

00:10:55.186 --> 00:11:00.526
wo ich weniger bundeln müsste oder mir eventuell einfach sagen könnte,

00:11:01.246 --> 00:11:05.326
wenn ich entsprechendes HTTP-Pre-Fetching in, keine Ahnung, meinen Metadaten

00:11:05.326 --> 00:11:07.826
konfigurieren kann und Und wenn ich aufs Bundlen verzichten kann,

00:11:07.986 --> 00:11:09.966
dann könnte ich mir das sparen.

00:11:09.986 --> 00:11:12.526
Aber weil ich in einer realen Welt lebe, wo ich den Bundler halt eben brauche,

00:11:13.086 --> 00:11:15.606
muss ich dieses Problem irgendwie lösen, dass ich mein Code-Splitting und meine

00:11:15.606 --> 00:11:18.546
Modularität wieder herstelle. Und das würde die Module-Federation dann für mich herstellen.

00:11:19.246 --> 00:11:25.106
Ja, genau, genau. Also wie schon gesagt, hatte DB2, war da die große Hoffnung,

00:11:25.126 --> 00:11:28.186
aber man hat dann recht schnell gesehen bei Performance-Benchmarks,

00:11:28.866 --> 00:11:33.706
dass das erstens nicht ganz so einfach zu konfigurieren ist und dass das zweitens

00:11:33.706 --> 00:11:38.346
dann auch nicht die gewünschten Performance-Vorteile mit sich bringt.

00:11:38.646 --> 00:11:43.506
Zum Beispiel ist es so, nur um ein Beispiel zu nennen, dass du erst ab einer

00:11:43.506 --> 00:11:47.266
gewissen Bundle-Größe wirklich Vorteile vom Zipping hast,

00:11:47.906 --> 00:11:51.926
weil dann ist die Wahrscheinlichkeit halt größer, dass ähnliche Muster immer

00:11:51.926 --> 00:11:56.206
und immer wieder vorkommen und darunter bei ganz, ganz kleinen Dateien hast

00:11:56.206 --> 00:11:59.866
du diese Vorteile nicht, Nicht, weil wir eben sich die Muster nicht wiederholen.

00:11:59.866 --> 00:12:04.146
Einfach nur um ein Beispiel da zu nennen. Ja, okay. Das stimmt natürlich.

00:12:05.926 --> 00:12:10.806
Na gut. Dann haben wir jetzt, glaube ich, den Überblick von der Module Federation hinbekommen.

00:12:10.886 --> 00:12:15.126
Wir haben ein Problem, dass die moderne Build Chain uns notwendigerweise bringt.

00:12:15.446 --> 00:12:18.506
Und wir lösen das auf. Und wir machen halt eben so Dinge wie halt eben dieses

00:12:18.506 --> 00:12:21.446
Laden und dieses Codesharing und das Codesplitting.

00:12:21.626 --> 00:12:26.026
Und ich gehe mal stark davon aus, das sind ja auch Dinge, die kann man ja konfigurieren.

00:12:26.386 --> 00:12:28.906
Aber ich gehe mal stark davon aus, dass so eine integrierte Lösung irgendwas

00:12:28.906 --> 00:12:33.826
Smartes macht, dass ich nicht manuell auflisten muss, welche Bestandteile einander

00:12:33.826 --> 00:12:37.446
geteilt werden können, sondern dass das irgendwie das automatisch, das ausfummelt.

00:12:38.516 --> 00:12:42.816
Ja, genau. Also theoretisch könnte ich es selber umsetzen, aber das wäre halt

00:12:42.816 --> 00:12:44.896
sehr aufwendig und fehleranfällig.

00:12:45.296 --> 00:12:49.936
Oder wenn es weniger fehleranfällig sein soll, dann halt noch viel, viel aufwendiger.

00:12:50.636 --> 00:12:54.456
Das Schöne bei Federation ist, es ist halt eine generische Lösung,

00:12:54.616 --> 00:12:59.476
die sich mit einer einfachen Konfigurationsdatei einrichten lässt und dann tut

00:12:59.476 --> 00:13:01.396
das Ding so, wie man es sich erwartet.

00:13:02.036 --> 00:13:08.816
Aber prinzipiell könnte ich ja alles selber bundeln. Ich könnte mit Externals arbeiten.

00:13:09.156 --> 00:13:13.096
Ich könnte mir irgendeine Logik schreiben, die aushandelt. Nehmen wir deine

00:13:13.096 --> 00:13:14.816
Abhängigkeit, nehmen wir meine.

00:13:14.976 --> 00:13:19.156
So nach dem Motto, du hast Library Version 10, ich habe 10.1.

00:13:19.376 --> 00:13:25.996
10.1 ist abwärtskompatibel, also nehmen wir einfach 10.1 und nutzen die auch an der Stelle von 10.0.

00:13:26.196 --> 00:13:30.116
Also das könnte ich natürlich alles händisch machen, Aber durch Federation bekomme

00:13:30.116 --> 00:13:32.036
ich das mehr oder weniger gratis.

00:13:32.036 --> 00:13:36.916
Da gibt es eine Konfigurationsdatei, wo ich ein paar Eckpunkte eintrage,

00:13:36.976 --> 00:13:41.976
wie zum Beispiel, was will ich teilen mit anderen Anwendungen und was will ich

00:13:41.976 --> 00:13:44.156
aber auch nur einmal laden.

00:13:44.156 --> 00:13:47.216
Also erstens, was will ich von mir teilen, von meinem Programmcode?

00:13:47.396 --> 00:13:51.776
Und zweitens, welche Abhängigkeiten will ich mit denen teilen,

00:13:51.916 --> 00:13:53.556
in welcher Version und so weiter?

00:13:53.916 --> 00:13:58.736
Und ja, dann macht halt Federation den Rest für mich automatisch. Okay.

00:13:59.276 --> 00:14:02.016
Das heißt, so wie du das jetzt gerade beschrieben hast, klingt es,

00:14:02.076 --> 00:14:05.456
als gäbe es sozusagen drei Aspekte des Teilens.

00:14:05.616 --> 00:14:08.996
Zum einen hast du das klassische Microfrontend, das mit seinen Kollegen ja irgendwie

00:14:08.996 --> 00:14:12.336
koexistieren muss und irgendwie so das Big Picture abbilden muss.

00:14:13.656 --> 00:14:16.256
Dann bieten die Dinger, wenn ich dich nicht richtig verstanden habe,

00:14:16.316 --> 00:14:18.616
auch noch Funktionalität, die andere importieren können.

00:14:18.916 --> 00:14:22.676
Das wäre so die Modulachse. Und jetzt hast du gerade auch noch gesagt,

00:14:22.736 --> 00:14:24.056
man kann auch noch Dependencies teilen.

00:14:24.096 --> 00:14:29.696
Also im Sinne von, ich installe irgendwas in Modul A und C...

00:14:30.990 --> 00:14:34.970
Kann das dann irgendwie nutzen, weil es das weiß, wobei Wissen tut es ja nicht,

00:14:35.030 --> 00:14:38.610
weil sie sind ja gesilot. Also wie funktioniert das? Und habe ich das überhaupt richtig beschrieben?

00:14:39.370 --> 00:14:44.210
Also um ganz konkret zu sein, die ersten beiden Punkte, die du genannt hast, sind dasselbe.

00:14:44.330 --> 00:14:48.590
Das ist das sogenannte Expose, wo ich sagen kann, ich gebe Programmcode frei

00:14:48.590 --> 00:14:52.610
von mir und der Programmcode kann in andere Anwendungen geladen werden.

00:14:52.970 --> 00:14:58.410
Dieser Programmcode könnte sowas Einfaches für eine Komponente sein oder vielleicht

00:14:58.410 --> 00:15:03.530
ein Verbund an Komponenten, eine Routenkonfiguration, die auf mehrere Komponenten

00:15:03.530 --> 00:15:05.590
verweist oder auch nur eine Funktion.

00:15:05.850 --> 00:15:09.150
Also das kann quasi alles sein, das ECMAScript hergibt.

00:15:10.010 --> 00:15:15.230
Also Sachen teilen, die man selber hat. Und das Zweite ist, Abhängigkeiten teilen.

00:15:15.390 --> 00:15:18.670
Und damit das funktioniert, brauchen wir Metadaten.

00:15:18.770 --> 00:15:23.830
Und Federation erzeugt tatsächlich beim Kompilieren eine Metadaten-Datei,

00:15:23.830 --> 00:15:28.930
wo zum Beispiel drinnen steht, ich brauche Angular in der Version X oder ich

00:15:28.930 --> 00:15:31.990
brauche RxJS in der Version Y.

00:15:32.590 --> 00:15:37.850
Da steht vielleicht aber auch drinnen, ich bin auch mit einer höheren meiner Version zufrieden.

00:15:37.950 --> 00:15:43.810
Diese Informationen kann man ja aus der Package JSON ableiten und somit landen

00:15:43.810 --> 00:15:45.990
die Informationen dann in diesen Metadaten.

00:15:46.070 --> 00:15:50.210
Die werden zur Laufzeit von der Shuttle, von der Hauptanwendung geladen und

00:15:50.210 --> 00:15:53.090
die Hauptanwendung kann das Ganze dann orchestrieren.

00:15:53.170 --> 00:15:58.090
Die weiß dann, aha, wir laden nur diese Version, weil die ist eh abwärtskompatibel

00:15:58.090 --> 00:16:02.090
und der andere ist auch damit zufrieden und vielleicht müssen wir von der Library

00:16:02.090 --> 00:16:06.130
zwei verschiedene Versionen laden, weil da brauche ich Version 2,

00:16:06.370 --> 00:16:10.490
da brauche ich Version 4 und die beiden sind halt miteinander nicht kompatibel,

00:16:10.550 --> 00:16:13.350
weil unterschiedliche Major-Versionen und so weiter.

00:16:13.590 --> 00:16:17.730
Okay, aber diese Metadaten sind nicht gleich die Package.json,

00:16:17.770 --> 00:16:19.710
das ist mehr als das, wenn ich das richtig verstehe.

00:16:20.764 --> 00:16:23.604
Es ist abgeleitet aus der Package Chasen, genau.

00:16:23.684 --> 00:16:30.464
Es ist ein internes Format, ein Federation-internes Format, eine JavaScript-Datei

00:16:30.464 --> 00:16:35.724
mit den ganzen Datenstrukturen, die man dazu braucht und auf die referenziert man halt.

00:16:35.924 --> 00:16:39.244
Okay, aber das ist nicht etwas, was jetzt manueller Wartung bedarf,

00:16:39.264 --> 00:16:43.024
das wird automatisch herbeikompiliert? Ja, genau.

00:16:43.184 --> 00:16:49.124
Also beim Kompilieren macht Federation für alles, was ich teilen möchte, ein eigenes Bundle.

00:16:49.344 --> 00:16:54.224
Das ist auch insofern notwendig, weil ja pro Ding, das ich teilen möchte,

00:16:54.364 --> 00:16:59.064
eine Aushandlung stattfinden kann, sowas wie Version X und X.1.

00:16:59.304 --> 00:17:00.984
Also nehmen wir X.1.

00:17:01.984 --> 00:17:05.864
Genau. Und das Ganze landet dann eben in diesen Metadaten.

00:17:07.844 --> 00:17:13.164
Okay. So. Das sind jetzt so die Dependencies, die aus der Package-JSON abgeleiteten Dinger.

00:17:13.244 --> 00:17:16.564
Zwei wollen irgendwie das gleiche RxJS oder ungefähr das gleiche RxJS haben.

00:17:16.644 --> 00:17:18.984
Es ist ausreichend kompatibel. Die Versionen überschneiden sich.

00:17:19.244 --> 00:17:22.724
Also brauchen wir nur eins als ein eigenes Bundle abzulegen,

00:17:22.784 --> 00:17:25.924
das dann die anderen laden können. Ja, genau.

00:17:54.364 --> 00:17:57.504
Irgendeinen Namen, den du Aufrufer wissen muss. Da möchte man ja in der Regel

00:17:57.504 --> 00:18:02.184
nicht den internen Dateinamen freigeben, weil dafür interessiert sich ja der

00:18:02.184 --> 00:18:03.284
Aufrufer vielleicht nicht.

00:18:03.384 --> 00:18:06.924
Da hat man die Möglichkeit, das Ganze auf einen schönen Namen zu mappen.

00:18:07.144 --> 00:18:11.884
Und das Tolle ist, der Aufrufer, die Shell, kann dann einen dynamischen Inboard

00:18:11.884 --> 00:18:18.124
verwenden und dort drinnen diesen Namen anführen und somit wird dann zur Laufzeit

00:18:18.124 --> 00:18:21.524
das Ding von dort drüben aus der anderen Anwendung geladen.

00:18:21.824 --> 00:18:25.844
Also wie wenn ich irgendwie so ein wenn irgendwas importiere aus den Node-Modules

00:18:25.844 --> 00:18:28.764
und ich einfach nur einen Namen angebe, tatsächlich meint das ja irgendeine

00:18:28.764 --> 00:18:32.564
Datei ganz tief versteckt, aber ich habe halt dieses Abkürzeln und ich kann

00:18:32.564 --> 00:18:35.684
sozusagen wirklich top-level-mäßig zwischen den einzelnen Micro-Frontends dann reden.

00:18:36.344 --> 00:18:41.084
Ja, genau. Und das Schöne daran ist, dass dein Framework davon nichts mitkriegt.

00:18:41.244 --> 00:18:46.984
Dein Framework glaubt, ah, der macht Lazy Loading. In Wirklichkeit ist es viel mehr als Lazy Loading.

00:18:47.084 --> 00:18:51.364
Wir laden was, was wir zur Laufzeit, zur Compile-Time noch nicht gekannt haben,

00:18:51.364 --> 00:18:53.904
Aber davon kriegt dein Framework nichts mit.

00:18:54.024 --> 00:18:59.744
Und das heißt in weiterer Folge, wir brauchen keine dreckigen Workarounds, keine Tricks.

00:18:59.784 --> 00:19:04.504
Wir nutzen einfach unser Framework, wie wir es immer nutzen, wie es gedacht ist.

00:19:04.644 --> 00:19:08.724
Und unterm Strich können wir allerdings dann fremde Sachen integrieren,

00:19:08.764 --> 00:19:12.664
zum Beispiel Plugins oder Microfrontends. Okay.

00:19:13.778 --> 00:19:19.878
Okay, das hört sich also tatsächlich wirklich so an, als einfach nur das Zusammenbringen

00:19:19.878 --> 00:19:23.238
von diesen Dingen, wie ich hätte gerne meine moderne Toolchain und alles,

00:19:23.358 --> 00:19:27.158
aber ich möchte es gerne so benutzen können, dass ich die Eclipscript-Modul-Features

00:19:27.158 --> 00:19:31.798
habe mit dynamischen Imports, mit diesem Mapping von prägnanten Namen auf irgendwelche

00:19:31.798 --> 00:19:34.818
Dateien und dass das alles einigermaßen gut zusammenspielt.

00:19:34.898 --> 00:19:37.818
Das heißt sozusagen, die eigentliche Magie da drin ist wirklich,

00:19:37.898 --> 00:19:42.938
dieses Mapping herzustellen und dieses Austüfteln von diesen ganzen Dingern,

00:19:42.938 --> 00:19:43.838
die geteilt werden können.

00:19:43.998 --> 00:19:49.258
Das wird in Metadaten gegossen und dann so aufbereitet, dass es konsumiert werden kann. Ja, genau.

00:19:50.558 --> 00:19:54.058
Da stellen sich mir jetzt so naiv so zwei Fragen.

00:19:54.298 --> 00:19:58.178
Zum einen, wie klappt denn das mit der TypeScript-Integration?

00:19:58.398 --> 00:20:01.258
Weil TypeScript ist ja in Angular auch eine gegebene Sache.

00:20:02.658 --> 00:20:06.758
Und ich muss ja was importieren. Das ist ja sozusagen virtuell.

00:20:06.818 --> 00:20:08.538
Das ist ja nur der Name von einem anderen Microfrontend.

00:20:08.678 --> 00:20:11.338
Das ist ja nicht eine Datei oder ein

00:20:11.338 --> 00:20:15.058
Modul-Mapping notwendigerweise dass TypeScript so nativ 1 zu 1 spricht?

00:20:15.138 --> 00:20:17.898
Oder ist es irgendwas, was dann TypeScript schon nativ spricht?

00:20:17.998 --> 00:20:20.018
Geht das einigermaßen nachlos oder muss man da was hexen?

00:20:20.478 --> 00:20:25.458
Ja und nein. Also es hängt davon ab, wie grobgranular ich Sachen nachlade.

00:20:25.638 --> 00:20:30.278
Wenn ich einfach weitere Komponenten nachlade, die angezeigt werden sollen,

00:20:30.398 --> 00:20:35.538
oder Routen nachlade, die auch angezeigt werden sollen, dann muss mein Anwendungscode

00:20:35.538 --> 00:20:37.418
nichts von den konkreten Typen wissen.

00:20:37.698 --> 00:20:42.538
Meinem Anwendungscode ist es komplett egal, welche Methoden die Komponente hat,

00:20:42.838 --> 00:20:45.718
oder welche Methoden die Routenkonfiguration hat.

00:20:45.838 --> 00:20:50.338
Ich will das Ding einfach nur laden, kann für mich ruhig unknown sein und ich

00:20:50.338 --> 00:20:52.678
sage dann zum Framework, jetzt bitte anzeigen.

00:20:52.898 --> 00:20:57.418
Und das Framework macht dann seine interne Magic. Also wenn es grobgranular ist.

00:20:57.918 --> 00:21:01.638
Also das wäre so quasi der Use Case von, ich bin Service A und ich will Service

00:21:01.638 --> 00:21:05.738
B in mir drin in die Welt setzen. Das wäre der Use Case. Ja, genau.

00:21:06.198 --> 00:21:10.558
Wenn ich jetzt mit dem Ding kommunizieren muss, quasi Properties setzen möchte

00:21:10.558 --> 00:21:15.158
oder Events draufkriegen möchte, dann brauche ich natürlich einen Vertrag.

00:21:15.178 --> 00:21:20.538
Dann muss ich ja wissen, welche Properties kann ich setzen und welche Events kann ich definieren.

00:21:20.938 --> 00:21:25.178
Und TypeScript will das natürlich beim Kompilieren bereits wissen.

00:21:26.218 --> 00:21:29.598
Und in dem Fall muss ich halt ein Interface teilen.

00:21:30.928 --> 00:21:35.308
Entweder mache ich mir das Interface selber aufgrund von einer Spezifikation

00:21:35.308 --> 00:21:39.188
oder ich habe irgendwo eine Library mit einem geteilten Interface.

00:21:39.388 --> 00:21:47.068
Es gibt auch den Ansatz, dass man aus den Metadaten von dort drüben die Interfaces generieren lässt.

00:21:47.388 --> 00:21:51.388
Somit muss man halt nur sicherstellen, dass man das Generieren neu anstößt,

00:21:51.388 --> 00:21:53.048
wenn sich dort drüben was ändert.

00:21:53.168 --> 00:21:57.088
Wir kennen genau die gleiche Vorgehensweise von der Netzwerkkommunikation,

00:21:57.288 --> 00:21:59.888
wo ich einen Service im Backend aufrufe.

00:21:59.888 --> 00:22:04.088
Da lässt man sich häufig auch irgendeinen Proxy, sagt man dann,

00:22:04.188 --> 00:22:08.248
generieren, der genauso ausschaut wie das Gegenüber auf der Backend-Seite.

00:22:10.008 --> 00:22:13.688
Swagger ist da ein Beispiel oder OpenAPI, wie es jetzt heißt.

00:22:14.328 --> 00:22:16.368
Ja, ich wollte es gerade sagen, das ist ja im Prinzip die gleiche Idee.

00:22:16.548 --> 00:22:19.568
Irgendwo ist spezifiziert, was es kann und es muss ja sozusagen auch nur wieder

00:22:19.568 --> 00:22:24.988
in Metadaten, die dann halt eben TypeScript-Typen sind, übersetzt werden und dann funktioniert das.

00:22:25.448 --> 00:22:29.088
Ja, genau. Aber okay, das kann ich mir trotzdem noch so einigermaßen herleiten,

00:22:29.088 --> 00:22:34.028
weil Interface entweder schreiben oder generieren und dann ist es ja letztlich

00:22:34.028 --> 00:22:37.708
dann noch ein bisschen wie ein Modul und dann kriegt TypeScript das ja schon mitgeschnitten.

00:22:37.848 --> 00:22:40.948
Es ist ja nicht etwas, was sich auf magische Weise irgendwie plötzlich manifestiert,

00:22:40.948 --> 00:22:43.748
sondern du musst es ja irgendwie explizit importieren und dann weiß TypeScript.

00:22:44.809 --> 00:22:47.289
Dann haben wir hier irgendwie ein Objekt, das muss dieses Interface implementieren

00:22:47.289 --> 00:22:52.609
und dann passiert ja eh TypeScript-Magie, die ja letztlich nur eine Illusion zur Compile-Zeit ist.

00:22:52.929 --> 00:22:56.789
Ja, genau, genau. Und was da vielleicht auch noch interessant ist,

00:22:56.929 --> 00:22:59.449
auch wenn das Ganze auf der technischen Ebene geht,

00:22:59.949 --> 00:23:05.169
wir machen ja Micro-Frontends, um zueinander entkoppelte Lösungen zu haben,

00:23:05.289 --> 00:23:09.129
die dann schlussendlich aber dann doch wieder in eine Lösung integriert werden.

00:23:09.369 --> 00:23:13.289
Das heißt, auf der logischen Ebene möchte ich natürlich meine Abhängigkeiten,

00:23:13.289 --> 00:23:16.109
meine Verträge so gering wie möglich halten.

00:23:16.269 --> 00:23:18.489
Da will ich so wenig wie möglich wissen.

00:23:18.889 --> 00:23:22.789
Eigentlich will ich gar nichts voneinander wissen, aber nachdem es ja dann doch

00:23:22.789 --> 00:23:27.689
schlussendlich ein Gesamtsystem ist, gibt es da eine Trade-off-Situation.

00:23:28.149 --> 00:23:32.269
Also ein paar Details muss ich dann doch vom Gegenüber wissen oder zumindest annehmen.

00:23:32.729 --> 00:23:37.289
Ja, ich wollte genau das gerade so fragen, weil das klingt ja alles gut,

00:23:37.909 --> 00:23:42.189
aber es ist ja sozusagen wirklich das Gegenteil von dem, was du ja mit den Microfrontends

00:23:42.189 --> 00:23:43.329
eigentlich erreichen möchtest.

00:23:43.429 --> 00:23:46.209
Und da wäre natürlich jetzt so die Frage, also du sagst das,

00:23:46.329 --> 00:23:49.129
das klingt einigermaßen offensichtlich, wir wollen ja, dass die Microfrontends

00:23:49.129 --> 00:23:51.989
voneinander isoliert sind, aber wir wollen sie auch Codesharing machen lassen.

00:23:53.649 --> 00:23:57.089
Also wie kommen wir dazu, Best Practices und wie hält man da dann die Entwicklerschaft

00:23:57.089 --> 00:24:01.149
davon ab, irgendwelchen Mist zu bauen, dass sie sich am Ende mit ihrer Architektur

00:24:01.149 --> 00:24:02.829
mehr Probleme schaffen, als sie sie lösen?

00:24:03.949 --> 00:24:08.029
Ja, also Codesharing ist da nicht so das Problem. Das passiert eh transparent,

00:24:08.229 --> 00:24:13.809
das Codesharing. Da kümmert sich Module Federation darum und es handelt einfach

00:24:13.809 --> 00:24:18.569
Versionen aus oder lädt zwei verschiedene Versionen. Davon bekomme ich auch nichts mit.

00:24:19.489 --> 00:24:25.769
Gravierender ist die Koppelung auf der API-Ebene, weil das will ich ja verhindern

00:24:25.769 --> 00:24:29.669
und auf der anderen Seite brauche ich es, weil es ja doch wieder ein Gesamtsystem ist.

00:24:29.949 --> 00:24:34.209
Und da sind wir in einem Bereich, der für Architektur ganz, ganz üblich ist,

00:24:34.309 --> 00:24:37.109
nämlich man muss irgendwie einen Mittelweg finden.

00:24:37.189 --> 00:24:40.169
Man muss sich über Trade-offs irgendwie Gedanken machen.

00:24:41.329 --> 00:24:45.749
Und ja, dazu analysiert man halt in der Regel die Geschäftsprozesse.

00:24:45.749 --> 00:24:53.369
Da gibt es auch ganz nette Workshop-Formate, wo man gemeinsam mit den Business-Experten

00:24:53.369 --> 00:24:55.329
den Geschäftsprozess analysiert,

00:24:55.349 --> 00:25:00.629
wo man die Leute in einen Raum einsperrt mit ganz vielen Post-its und die kleben

00:25:00.629 --> 00:25:05.889
dann quasi mit den Post-its diesen Geschäftsprozess und dann bringt man halt das Wissen zusammen.

00:25:05.889 --> 00:25:10.589
Das Wissen von den Domänexperten und das Wissen von den Entwicklern,

00:25:10.649 --> 00:25:13.929
Entwicklerinnen und gemeinsam überlegt man sich dann auch,

00:25:14.049 --> 00:25:19.709
wo man die Grenzen zieht, also wo man dieses gesamte Konstrukt am besten aufgliedern

00:25:19.709 --> 00:25:21.889
kann in kleinere Häppchen,

00:25:22.089 --> 00:25:26.029
die als separate Anwendungen von einzelnen Teams umgesetzt werden.

00:25:26.029 --> 00:25:31.349
Aber das ist die große Kunst und da gibt es häufig auch keine perfekten Lösungen,

00:25:31.389 --> 00:25:36.009
aber das Ziel ist es halt eine gute Lösung zu finden,

00:25:36.169 --> 00:25:41.389
wo ich so wenig Kopplung wie möglich habe und so viel wie nötig.

00:25:42.010 --> 00:25:45.010
Ja, das ist ja das klassische Problem. Du musst ja irgendwie die Silos definieren

00:25:45.010 --> 00:25:49.310
und sagen, du bist ein Service, der alleine steht und diese Funktionalität bauen wir noch da mit rein.

00:25:49.590 --> 00:25:52.890
Das ist ja letztlich auch irgendwie zu einem gewissen Grad dann Ermessenssache. Genau.

00:25:53.410 --> 00:25:58.650
Es gibt eigentlich nur zwei Einflussfaktoren, weil du gerade Silo gesagt hast,

00:25:58.770 --> 00:26:01.210
die die Größe des Silos definieren.

00:26:01.370 --> 00:26:06.810
Und zwar die minimale Größe des Silos muss so dimensioniert sein,

00:26:06.970 --> 00:26:10.770
dass zusammengehörige Features in einem Silo platziert werden.

00:26:10.770 --> 00:26:15.330
Weil ich will ja nicht zwischen den Silos, zwischen den Geschäftsdomänen,

00:26:15.390 --> 00:26:19.750
Verticals, wie man auch immer dazu sagen möchte, ständig hin und her wechseln müssen.

00:26:19.970 --> 00:26:27.330
Ein Use Case oder ein Benutzerflow sollte möglichst in einem Silo abgedeckt sein aus UI, UX Gründen.

00:26:27.330 --> 00:26:31.890
Und die maximale Größe ist halt die Team Size, weil ich will ja,

00:26:31.930 --> 00:26:37.090
dass ein Team sich um einen Silo kümmern kann, damit die möglichst autark sein können.

00:26:37.210 --> 00:26:40.870
Wäre es blöd, wenn jetzt wieder vier Teams am gleichen Silo arbeiten,

00:26:41.110 --> 00:26:44.670
da braucht man dann wieder ständig Koordinationsaufgaben.

00:26:44.810 --> 00:26:51.110
Das heißt, zwischen acht und zwölf Leute sollten reichen, um den Silo zu implementieren.

00:26:53.230 --> 00:26:56.690
Ja, das ist natürlich das klassische Micro-Frontend-Problem,

00:26:56.790 --> 00:27:00.670
aber speziell, wo wir jetzt diese Micro-Frontends haben, die einander ja nicht

00:27:00.670 --> 00:27:02.450
nur so grob integrieren können,

00:27:02.570 --> 00:27:05.250
sondern die ja tatsächlich Features voneinander importieren können,

00:27:05.350 --> 00:27:08.810
nicht diese impliziten Dependencies fürs Codesplitting, sondern wirklich Microservice

00:27:08.810 --> 00:27:11.990
B Canvas, das hätte ich gerne bei mir in A, joink, das importiere ich mir jetzt.

00:27:11.990 --> 00:27:16.950
Also das ist ja letztlich im Prinzip das Kernproblem der Softwareentwicklung,

00:27:17.030 --> 00:27:21.150
dass man ja eigentlich alles schön aufteilen könnte und dann gibt es halt irgendwo

00:27:21.150 --> 00:27:24.490
den Punkt, wo man sagt, okay, da gibt es halt nun mal Verschränkungen und Verstrickungen

00:27:24.490 --> 00:27:28.010
und das ist halt dann das, was, wenn es schlecht gemacht ist,

00:27:28.050 --> 00:27:29.330
zu irgendwie Spaghetti-Code führt,

00:27:29.530 --> 00:27:33.430
wenn es OOP ist, führt es zu irgendwelchen Service-Manager-Klassen und da ist

00:27:33.430 --> 00:27:35.710
halt immer so die Frage, wie hält man das so vom Entarten ab?

00:27:35.710 --> 00:27:38.650
Ich kenne ja von vielen, vielen anderen Leuten, die in diesem Podcast schon

00:27:38.650 --> 00:27:41.090
waren, die haben genau das Gleiche gesagt für die Architektur wie du jetzt.

00:27:41.170 --> 00:27:44.530
Man muss die Domänen-Experten und die Entwicklerinnen und Entwickler in einen

00:27:44.530 --> 00:27:47.730
Raum sperren und wirklich erst rausgehen lassen, wenn die die gleiche Sprache

00:27:47.730 --> 00:27:50.050
sprechen und ihre ganzen Prozesse aufeinander abgestimmt haben,

00:27:50.170 --> 00:27:55.570
dass die Leute, die das Silo implementieren, wissen, wie die Silos definiert

00:27:55.570 --> 00:27:59.070
sind und dass halt eben dann diejenigen, die diese Geschäftsprozesse im Griff

00:27:59.070 --> 00:28:01.630
haben und modellieren, dass die sich da drin dann wieder gespiegelt sehen.

00:28:02.110 --> 00:28:05.730
Ja. Ich frage mich halt immer, wie gut kriegt man das so hin,

00:28:05.790 --> 00:28:07.650
da die Evolution immer drin abzubilden?

00:28:07.930 --> 00:28:11.790
Weil solche Anforderungen, die ändern sich ja, die Geschäftsprozesse mutieren.

00:28:12.410 --> 00:28:14.850
Irgendwann stellt man dann fest, hoppla, unser Team ist jetzt nicht mehr zwölf

00:28:14.850 --> 00:28:18.950
Leute, sondern irgendwie 18 Leute groß. Wir müssen da etwas umstrukturieren

00:28:18.950 --> 00:28:19.930
aus irgendwelchen Gründen.

00:28:20.130 --> 00:28:23.990
Also wie kriegt man so diese Silodefinition und dann auch Redefinition in der

00:28:23.990 --> 00:28:26.770
täglichen Praxis gelöst? Weil du kannst ja nicht immer die ganze Firma in einen

00:28:26.770 --> 00:28:28.210
Raum sperren, oder kannst du das? Ja.

00:28:29.659 --> 00:28:33.499
Naja, zumindest Vertreter der einzelnen Teams, das wäre schon nicht schlecht,

00:28:33.599 --> 00:28:37.679
wenn ich sage, ich habe sieben Teams, die daran arbeiten, wären das mal sieben

00:28:37.679 --> 00:28:41.199
fachliche Leute und dann ein paar Domänexperten.

00:28:43.219 --> 00:28:46.859
Ja, aber was du jetzt da angesprochen hast, das ist ein wichtiger Punkt,

00:28:47.059 --> 00:28:51.599
also die müssen sich gemeinsam darauf einigen, ein gemeinsames Verständnis schaffen,

00:28:51.859 --> 00:28:56.679
die finden dann auch gute Domänenschnitte, keine perfekten, weil die gibt es

00:28:56.679 --> 00:28:58.119
nicht, aber gute Domänenschnitte.

00:28:58.119 --> 00:29:00.579
Und dann kann man mal los implementieren.

00:29:00.659 --> 00:29:05.959
Wobei, und das ist auch wichtig, das jetzt Gesagte ist nur einer von mehreren Aspekten.

00:29:05.979 --> 00:29:12.059
Es gibt ja noch weitere Aspekte, wie zum Beispiel, dass man zwischendurch mal refactoren muss.

00:29:12.059 --> 00:29:17.419
Diese Erkenntnis ist ja mittlerweile auch schon im, ich sage mal,

00:29:17.519 --> 00:29:21.799
ID-Fair-Management angekommen, dass man zwischendurch mal refactoren muss.

00:29:21.899 --> 00:29:23.479
Das war vor 20 Jahren noch anders.

00:29:23.599 --> 00:29:27.559
Da habe ich mal zu einem Kunden gesagt, ja, wir müssen das Ding langsam refactoren

00:29:27.559 --> 00:29:31.359
nach 17 Iterationen und der hat gesagt, nee, zahle ich nicht,

00:29:31.439 --> 00:29:35.919
weil refactoren heißt, du hast es nicht ordentlich gemacht. Hättest du es gleich

00:29:35.919 --> 00:29:38.259
ordentlich gemacht, müsstest du jetzt nicht refactoren.

00:29:38.419 --> 00:29:42.259
Aber das ist 20 Jahre her. Ich glaube, mittlerweile haben wir das Verständnis

00:29:42.259 --> 00:29:46.079
dafür, dass wir Aufräumiterationen brauchen. Ja.

00:29:46.839 --> 00:29:51.039
Das ist ein weiterer Aspekt. Und dann gibt es auch technische Maßnahmen zur

00:29:51.039 --> 00:29:55.859
Entkopplung, wie zum Beispiel, wenn es nur um Daten geht, die hin und her flutschen,

00:29:55.899 --> 00:29:59.919
kann ich das über Message Queuing, Eventing im Backend machen.

00:30:00.279 --> 00:30:04.639
Das Schöne bei Eventing ist ja, es ist unaufdringlich. Also ich schicke ein

00:30:04.639 --> 00:30:10.119
Event raus, da hat jemand ein Produkt gebucht, ein Produkt gekauft und jeder,

00:30:10.199 --> 00:30:13.759
der sich dafür interessiert, der behandelt das Event auf seine Art und Weise.

00:30:13.959 --> 00:30:16.879
Jeder, der sich nicht dafür interessiert, ignoriert es einfach.

00:30:16.879 --> 00:30:20.859
Und da gibt es noch ein paar weitere Techniken, wie zum Beispiel,

00:30:20.999 --> 00:30:25.039
dass ich sage, naja, ich habe ein Produkt hier, ich habe ein Produkt dort,

00:30:25.079 --> 00:30:27.079
aber eigentlich schauen die ganz anders aus.

00:30:27.539 --> 00:30:32.159
Insofern muss ich das Produkt gar nicht teilen. Es sind einfach zwei ganz verschiedene

00:30:32.159 --> 00:30:36.659
Perspektiven auf etwas, das vielleicht in der Welt das gleiche Ding ist,

00:30:36.779 --> 00:30:41.119
vielleicht in der Welt aber auch unterschiedliche Dinge repräsentiert und nur

00:30:41.119 --> 00:30:42.659
zufällig gleich heißt. ist.

00:30:43.199 --> 00:30:48.419
Konkretes Beispiel, beim Produkt, das Produkt aus der Shop-Perspektive ist ganz

00:30:48.419 --> 00:30:51.919
was anderes, wie das Produkt aus der Verrechnungsperspektive.

00:30:51.979 --> 00:30:56.939
Beim Verrechnen sind es ein paar ganz wenige Daten, vor allem der Preis und

00:30:56.939 --> 00:31:00.019
die Bezeichnung und vielleicht die Stückanzahl.

00:31:00.139 --> 00:31:04.959
Aus Shop-Perspektive ist es ein riesengroßes Ding, weil ich will ja das Produkt

00:31:04.959 --> 00:31:08.599
dem potenziellen Kunden schmackhaft machen, damit er sich fragt,

00:31:08.599 --> 00:31:11.559
ja, wie kann ich überhaupt ohne dem Ding leben? Ja.

00:31:12.555 --> 00:31:14.675
Ja, okay. Das ist ja dann das klassische Problem. Irgendwie,

00:31:14.675 --> 00:31:17.175
wo sind Dinge wirklich unterschiedlich und wo ist es irgendwie ein Ding mit

00:31:17.175 --> 00:31:20.355
zwei verschiedenen irgendwie Linsen, die da drauf gerichtet werden und dann

00:31:20.355 --> 00:31:22.515
wird es so oder so halt eben dargestellt.

00:31:22.595 --> 00:31:26.235
Aber das ist so, ja, mehr oder weniger die klassische Software-Architektur, ne?

00:31:26.415 --> 00:31:32.015
Also, letztlich wäre dann so in dem Zusammenhang das nicht was Besonderes,

00:31:32.015 --> 00:31:36.975
sondern es wäre ja eigentlich nur so Software-Architektur, wie es sich gehört.

00:31:37.855 --> 00:31:42.275
Ja, genau. Also ich glaube, Software-Architektur ist ja an und für sich nichts Besonderes.

00:31:42.435 --> 00:31:46.975
Es geht ja unterm Strich darum, dass ich halt bewusste Entscheidungen treffe,

00:31:47.095 --> 00:31:53.235
dass ich mich konsequent an ein paar Richtlinien halte oder ein paar Best Practices halte.

00:31:53.415 --> 00:31:56.295
Und dann kommen halt noch die Erfahrungswerte dazu.

00:31:56.455 --> 00:31:59.935
Wann setze ich welches Muster ein? Wann lohnt sich Eventing?

00:32:00.075 --> 00:32:05.695
Das ist halt etwas, was man vielleicht nicht unbedingt so in der Theorie hundertprozentig

00:32:05.695 --> 00:32:09.755
vermitteln kann, wo, wie gesagt, Erfahrungswerte Sinn machen. Ja.

00:32:12.815 --> 00:32:15.995
Und wo wir jetzt gerade dann bei dieser normalen Softwarearchitektur sind,

00:32:16.075 --> 00:32:21.695
dann ist ja quasi die Module Federation dann letztlich die Manifestation in

00:32:21.695 --> 00:32:24.155
technischer Sicht dessen, was du dann ja machen würdest.

00:32:24.255 --> 00:32:27.095
Nämlich, wir haben jetzt sehr viel darüber gesprochen, wie wir Entscheidungen

00:32:27.095 --> 00:32:30.555
treffen und definieren und wie das alles funktioniert.

00:32:30.695 --> 00:32:34.255
Und letztlich flutscht es halt dann nur richtig gut, Gut, wenn die Module-Federation

00:32:34.255 --> 00:32:37.695
das sozusagen enabelt, indem sie halt die ganzen schwierigen Probleme,

00:32:37.735 --> 00:32:41.055
die halt im Prinzip ja nur technisch nachgeordnete Probleme sind,

00:32:41.095 --> 00:32:42.955
wie halt das Code-Splitting muss irgendwie ordentlich sein,

00:32:43.055 --> 00:32:47.315
dass es schön schnell lädt und dass die Dependencies irgendwie einigermaßen wohl definiert sind.

00:32:47.655 --> 00:32:50.235
Das macht es ja nur möglich sozusagen, es unlockt es ja nur.

00:32:50.575 --> 00:32:55.915
Ja genau, es ist quasi ein Enabler, ein technischer Enabler von dieser Idee

00:32:55.915 --> 00:32:57.675
der Aufteilung in Silos.

00:32:59.538 --> 00:33:05.658
Okay. Sag mal, wie ist denn eigentlich das Verhältnis von Module Federation zu Angular insgesamt?

00:33:06.098 --> 00:33:10.338
Also ist das irgendwie so ein spezieller Pattern, eine Software,

00:33:10.458 --> 00:33:11.818
ein Plugin? Wie verhält sich das zueinander?

00:33:12.598 --> 00:33:17.918
Ja, also das Angular-Team unterstützt selber gar keine Micro-Frontend-Architekturen.

00:33:18.018 --> 00:33:22.718
Bei Angular hat man ja dieses riesengroße Monorepo und die gehen davon aus,

00:33:22.738 --> 00:33:27.098
dass ich immer alles gemeinsam kompilieren kann, was ja auch Sinn macht,

00:33:27.218 --> 00:33:29.878
wenn es geht, weil es zu mehr Performance führt.

00:33:29.878 --> 00:33:34.978
Also bei Microsoft hat man die Idee nicht, dass man verschiedene Anwendungen,

00:33:34.978 --> 00:33:38.898
Microsoft sage ich bei Google, hat man die Idee nicht, dass man verschiedene

00:33:38.898 --> 00:33:43.298
Anwendungen, die unabhängig voneinander entwickelt wurden, zusammenbringt.

00:33:43.458 --> 00:33:45.558
Da hat man eher das Monorepo-Gedanken.

00:33:46.378 --> 00:33:49.758
Trotzdem fragen die natürlich, wir wollen das ermöglichen und wenn sich die

00:33:49.758 --> 00:33:55.578
Community da darum kümmert, warum nicht, und die haben ein paar Einsprungspunkte geschaffen.

00:33:55.658 --> 00:34:00.098
Man kann zum Beispiel den Build-Prozess innerhalb der CLI austauschen,

00:34:00.678 --> 00:34:01.898
was wir auch gemacht haben.

00:34:02.318 --> 00:34:07.198
Wir haben da quasi einen eigenen sogenannten Builder geschrieben,

00:34:07.498 --> 00:34:11.258
ist auch Open Source, und dieser Builder macht nur eine Sache,

00:34:11.258 --> 00:34:17.218
Er aktiviert Federation und dann delegiert er an die Standardlogik von der CLI

00:34:17.218 --> 00:34:21.098
weiter, weil schlussendlich will man ja nicht von der CLI abweichen.

00:34:21.178 --> 00:34:25.798
Man hätte gerne den Angular-Standard, aber zusätzlich halt noch diesen Schalter

00:34:25.798 --> 00:34:29.878
umgelegt, der Federation aktiviert und im Wesentlichen macht unser Plugin nur

00:34:29.878 --> 00:34:33.818
das, Federation aktivieren und dann die Standardlogik delegieren.

00:34:34.938 --> 00:34:38.858
Und wie wir ja gehört haben, Federation ist ja im Prinzip diese Metadaten und

00:34:38.858 --> 00:34:42.518
die Integration der Metadaten in das große gesamte Bild, also Module Federation

00:34:42.518 --> 00:34:45.898
quasi als Plugin zu verstehen, ist jetzt nicht komplett falsch.

00:34:46.518 --> 00:34:49.118
Ja, genau. Okay, aber wer sind wir?

00:34:50.599 --> 00:34:54.039
Wir sind Angola Architects, also ich und meine lieben Kollegen,

00:34:54.219 --> 00:35:00.379
die relativ früh schon gesehen haben, dass sich mit Federation ganz,

00:35:00.439 --> 00:35:02.899
ganz viele Probleme einfach in Luft auflösen.

00:35:02.979 --> 00:35:07.159
Probleme, die viele unserer Kunden mit großen Projekten gehabt haben.

00:35:07.159 --> 00:35:13.279
Man kann sich vorstellen, ab dem Zeitpunkt, wo man Microservices gemacht hat,

00:35:13.539 --> 00:35:17.679
hat man sich natürlich die Frage gestellt, ja und was ist jetzt mit dem Frontend?

00:35:18.159 --> 00:35:23.139
Und darauf hat es ja lange Zeit lang keine ordentliche Antwort gegeben.

00:35:23.139 --> 00:35:26.199
Klar, man hat schon immer mit iFrames arbeiten können.

00:35:26.879 --> 00:35:31.259
Wahrscheinlich ist der iFrame nicht unbedingt das beliebteste HTML-Element.

00:35:31.579 --> 00:35:36.499
Also wenn ich eine Top-10-Liste mache mit den beliebtesten HTML-Elementen,

00:35:36.499 --> 00:35:38.999
der iFrame gehört da wahrscheinlich eher nicht dazu.

00:35:39.639 --> 00:35:43.699
Nee, ich meine, die ersten zehn Plätze werden ja alle von Div belegt mit verschiedenen

00:35:43.699 --> 00:35:45.279
Klassen, das wissen wir ja alle. Ja, genau.

00:35:45.779 --> 00:35:52.139
Und Marquis, ganz wichtig. Ein Stück 90er-Jahre, dass ich mir damit zurückhole.

00:35:54.879 --> 00:36:00.919
Manche Leute haben dann auch begonnen, Web-Components dynamisch zu laden,

00:36:00.919 --> 00:36:04.919
aber man hat dazu halt immer viel eigenen Infrastruktur-Code gebraucht.

00:36:06.019 --> 00:36:10.959
Und insofern haben wir relativ schnell gesehen, jawohl, Federation löst da viele

00:36:10.959 --> 00:36:13.559
Probleme, die unsere Kunden haben. Mhm.

00:36:14.339 --> 00:36:17.239
Das wäre nämlich jetzt noch meine nächste Frage gewesen, weil im Prinzip,

00:36:17.359 --> 00:36:21.779
ja, wenn man jetzt von der Plattform her käme, ein Microfrontend wäre ja tatsächlich

00:36:21.779 --> 00:36:25.539
als Web-Component mehr oder minder ein natürlicher Match, um halt den Preis

00:36:25.539 --> 00:36:29.139
nicht integriert zu sein in die Welt von was immer das Framework ist.

00:36:29.139 --> 00:36:32.399
Was ja gegebenenfalls genau das ist, was man haben möchte, weil dann kann es

00:36:32.399 --> 00:36:35.099
mit allen arbeiten, aber was man halt gegebenenfalls auch nicht haben möchte,

00:36:35.179 --> 00:36:39.439
weil dann gibt es halt Reibungsverluste an den API-Grenzen.

00:36:41.259 --> 00:36:45.019
Es ist jetzt ja schon so, wenn ich es richtig verstanden habe, dass die,

00:36:45.219 --> 00:36:49.719
also wenn ich jetzt wirklich Module Federation nutzen möchte,

00:36:49.899 --> 00:36:54.199
unter anderem halt auch über diesen Import-Trick am Ende die Möglichkeit haben

00:36:54.199 --> 00:36:59.659
möchte, einfach per Namensreferenz anderes Microfrontend in mein Microfrontend zu importieren.

00:37:01.059 --> 00:37:04.619
Haben wir ja schon gesagt, dieser API-Contract, der, was jetzt so APIs angeht,

00:37:04.619 --> 00:37:09.279
der prägt sich dann als TypeScript-Interface gegebenenfalls aus und den Namen

00:37:09.279 --> 00:37:12.459
von dem Import, den muss man halt eben einfach wissen. Ja, genau.

00:37:13.359 --> 00:37:16.219
Okay, also ich muss einfach wissen, wenn ich jetzt Microfrontend A bin,

00:37:16.379 --> 00:37:22.019
das andere Ding heißt Microfrontend B, fertig und okay.

00:37:22.559 --> 00:37:27.719
Genau, also ich brauche auch ein paar Metadaten jenseits der technischen Metadaten,

00:37:27.759 --> 00:37:32.539
die ich der Shell gebe. Die Shell muss ja wissen, unter welchen Namen sie wo was findet.

00:37:33.864 --> 00:37:39.664
Okay, also so im Sinne von, ich importiere das und dann muss ich sozusagen dieses

00:37:39.664 --> 00:37:44.304
Mapping haben oder im Sinne von irgendwie einem automatischen Prozess, ein Auto-Discovery.

00:37:44.444 --> 00:37:49.444
Ich deklariere, hier sei jetzt Microservice B und Shell weiß automatisch Microservice

00:37:49.444 --> 00:37:53.224
B im Map zu, Datei so und so, Bootstrap-Prozedur so und so, das alles.

00:37:53.224 --> 00:37:58.424
Ja genau, das wären dann irgendwelche weiteren Metadaten, die ich halt ins Spiel bringen muss.

00:37:58.644 --> 00:38:03.924
Im einfachsten Fall geht einfach die Shell Hard-Codiert auf einen bestimmten Namen los.

00:38:04.124 --> 00:38:11.024
Die geht davon aus, es gibt immer etwas, das den Namen Shop-Card hat oder immer

00:38:11.024 --> 00:38:15.844
etwas, das den Namen Payment-Invoice hat. Das wäre die einfachste Lösung.

00:38:16.064 --> 00:38:19.684
Wenn ich es noch dynamischer haben möchte, dann muss sich der Shell halt genau

00:38:19.684 --> 00:38:24.144
die gleichen Daten über irgendwelche Konfigurationsdateien bereitstellen.

00:38:24.504 --> 00:38:28.964
Könnten JSON-Dateien sein, könnte aber auch irgendeine Web-API sein.

00:38:29.104 --> 00:38:34.764
Ich spreche dann immer gern von einem NBM-Repo für Microfrontends.

00:38:34.964 --> 00:38:39.404
Also es ist kein NBM, aber es ist genauso eine Registry mit Metadaten,

00:38:39.484 --> 00:38:42.744
die halt der Shell sagt, was es gibt und wo es das gibt.

00:38:43.904 --> 00:38:48.204
Okay, alles klar. Das macht ja einigermaßen Sinn. Irgendwie muss es ja wiedergefunden werden.

00:38:48.924 --> 00:38:51.584
Welches also ich jetzt habe? Wenn ich also jetzt Module Federation habe,

00:38:51.644 --> 00:38:53.864
ich habe das, was ja mehr oder minder ein Plugin ist, aktiviert.

00:38:54.544 --> 00:38:59.764
Wenn ich jetzt da in meinem Alltag bin, als wirklich so Angular-Nerd im Frontend,

00:38:59.884 --> 00:39:03.344
ich rendere den lieben langen Tag Komponenten raus, aber das Big Picture machen

00:39:03.344 --> 00:39:06.424
halt die Software-Architekten, damit bin ich nur mittelbar irgendwie involviert.

00:39:06.764 --> 00:39:09.224
Wie viel ändert sich eigentlich an meinem Alltag, wenn ich jetzt da wirklich

00:39:09.224 --> 00:39:12.744
nur meine Komponenten rausrendere, meine Frontendschreiber, meine Testschreiber,

00:39:12.744 --> 00:39:15.084
so den ganzen Kram. Ja. Hat das was für mich?

00:39:16.424 --> 00:39:21.024
Wahrscheinlich wenig. Wenn man es gut macht, dann wird es wenig Unterschied

00:39:21.024 --> 00:39:22.984
für mich machen. Das ist zumindest das Ziel.

00:39:23.424 --> 00:39:28.304
Damit es allerdings möglich ist, und da sind wir auch schon bei den Kosten von

00:39:28.304 --> 00:39:31.224
so einer Architektur, brauche ich ein Plattform-Team.

00:39:31.544 --> 00:39:35.744
Es muss kein riesengroßes Team sein. Ich habe Projekte gesehen,

00:39:35.864 --> 00:39:40.344
wo sich zwei, drei Leute um mehrere Dutzend Feature-Teams kümmern.

00:39:40.884 --> 00:39:43.884
Aber ich brauche ein paar Leute, die halt Entscheidungen treffen,

00:39:44.264 --> 00:39:50.664
die Best Practices definieren, die Beispiele und Templates erzeugen und die

00:39:50.664 --> 00:39:53.924
vielleicht auch sogar ein paar Hilfs-Libraries erzeugen,

00:39:53.924 --> 00:39:59.084
damit die eigentlichen Feature-Teams möglichst geschmeidig arbeiten müssen und

00:39:59.084 --> 00:40:03.424
sich nicht über technische Sachen von Codesharing und Co. Gedanken machen.

00:40:04.580 --> 00:40:09.060
Das erfahre ich immer als relativ schwer zu verkaufen. Also so,

00:40:09.080 --> 00:40:10.920
wenn ich jetzt so den Leuten sage, was ihr wirklich braucht,

00:40:11.000 --> 00:40:14.500
ist, du hast das Plattformteam genannt, ich nenne es immer so Infrastrukturabteilung.

00:40:15.400 --> 00:40:18.380
Die Leute, die es nicht machen, weil das ist ja genauso wie mit der Softwarearchitektur,

00:40:18.380 --> 00:40:20.740
wenn man es nicht bewusst macht, passiert es halt trotzdem.

00:40:21.060 --> 00:40:23.520
Es passiert halt nur wahrscheinlich auf suboptimale Art und Weise,

00:40:23.600 --> 00:40:26.460
weil niemand den Hut auf hat und niemand das wirklich als definierte Aufgabe

00:40:26.460 --> 00:40:27.420
jetzt für sich versteht.

00:40:28.560 --> 00:40:31.760
Also wie kriegt man das dann, wie kriegt man das tatsächlich den Leuten verkauft,

00:40:31.760 --> 00:40:34.420
dass sie das brauchen und dass die Entscheider wirklich wissen,

00:40:34.480 --> 00:40:37.200
ich brauche hier Leute, wo ich jetzt nicht unmittelbar sagen kann,

00:40:37.280 --> 00:40:42.020
ich finde mein Shopping-Card-Team in meinem UI wieder, sondern das ist wirklich die Infrastruktur.

00:40:42.140 --> 00:40:44.760
Also das kommt ja aus dem realen Leben, die ist halt immer unterfinanziert.

00:40:45.340 --> 00:40:49.440
Ja, genau. Also ich sehe da zwei Dimensionen. Die eine Dimension ist,

00:40:49.620 --> 00:40:53.920
dass die Diskussion wahrscheinlich gar nicht so groß sein wird,

00:40:54.020 --> 00:40:58.380
wenn es um ein riesengroßes Projekt geht, Wo ganz, ganz viele Teams zusammenspielen.

00:40:58.500 --> 00:41:02.120
Ein Dutzend Teams plus minus, ein Dutzend Teams plus minus.

00:41:02.240 --> 00:41:07.200
Da wird es wahrscheinlich jedem klar sein, dass man auch irgendein Infrastruktur-Team

00:41:07.200 --> 00:41:09.500
braucht, das quasi, das drumherum baut.

00:41:10.800 --> 00:41:15.960
Noch dazu brauche ich ja wahrscheinlich so ein Infrastruktur-Team auch ohne

00:41:15.960 --> 00:41:20.680
Micro-Frontends, weil gewisse Vorgaben gibt es ja auch ohne Micro-Frontends.

00:41:20.680 --> 00:41:23.960
Vielleicht nicht ganz so viele, vielleicht brauche ich auch nicht ganz so viele

00:41:23.960 --> 00:41:26.920
Templates oder Lösungen,

00:41:27.140 --> 00:41:32.640
weil ich dann eher auf Standard-Architekturen aufsetze, aber sowas wie ein Design-System

00:41:32.640 --> 00:41:37.260
werde ich trotzdem brauchen oder jemand, der sagt, so machen wir Authentifizierung,

00:41:37.400 --> 00:41:40.380
Single-Sign-On bei uns im Gesamtsystem.

00:41:40.380 --> 00:41:46.140
Aber um es kurz zu sagen, umso größer das Projekt, umso mehr Teams,

00:41:46.340 --> 00:41:48.880
umso kleiner wird die Diskussion sein.

00:41:49.220 --> 00:41:54.060
Wenn ich nur ein, zwei, drei Teams habe, dann muss man sich eh die Frage stellen,

00:41:54.180 --> 00:41:59.560
ob sich Microfronted-Architekturen lohnen oder ob der Oberheit dafür nicht zu groß sein wird.

00:41:59.560 --> 00:42:03.840
Wenn ich zwei Teams habe, die sich wunderbar in eine Monorepo vertragen,

00:42:03.920 --> 00:42:08.360
die sich auch wunderbar ohne großen Aufwand abstimmen können, wann wird deployed,

00:42:08.780 --> 00:42:12.920
wann ziehen wir die Rekt-Version hoch, wann ziehen wir die Angular-Version hoch,

00:42:13.060 --> 00:42:15.600
dann wird das wahrscheinlich die einfachere Lösung sein.

00:42:15.740 --> 00:42:18.520
Da brauche ich keine Microfrontends dafür.

00:42:19.220 --> 00:42:23.400
Ja. Hast du da irgendwie so Erfahrungswerte, ab wann das anfängt Sinn zu machen?

00:42:23.480 --> 00:42:27.800
Also wann empfiehlst du so üblicherweise, das Monorepo zu verlassen und zu sagen,

00:42:27.840 --> 00:42:30.020
so, jetzt machen wir mal ernsthaft Microfrontends?

00:42:30.920 --> 00:42:36.440
Es ist von zwei Aspekten abhängig. Der eine Aspekt ist, wie viele Teams habe ich?

00:42:36.460 --> 00:42:40.680
Und ich würde mal sagen, ab zwei Teams kann man schon darüber nachdenken.

00:42:41.040 --> 00:42:45.960
Abhängig vom zweiten Aspekt. Und der ist die Unternehmenskultur. Wie...

00:42:47.143 --> 00:42:51.683
Stark kann man verlangen, dass Teams in einem Monorepo zusammenarbeiten,

00:42:51.883 --> 00:42:54.123
dass sich Teams untereinander abstimmen.

00:42:54.863 --> 00:42:58.643
In manchen Unternehmen ist das bei einer kleinen Anzahl von Teams überhaupt

00:42:58.643 --> 00:43:01.483
kein Problem. Mit klein meine ich zwei bis fünf.

00:43:01.723 --> 00:43:05.063
Es gibt aber auch Unternehmen, wo das ein riesengroßes Problem ist,

00:43:05.183 --> 00:43:08.103
weil vielleicht die Leute auf der Welt verstreut sitzen.

00:43:08.403 --> 00:43:12.103
Oder weil das verschiedene fachliche Teams sind.

00:43:12.103 --> 00:43:17.663
Denken wir ans E-Banking, da haben wir die Leute, die sich ums Konto kümmern, dann gibt es Leute,

00:43:17.823 --> 00:43:22.803
die sind Experten für meinen Kredit und wiederum andere Leute sind Experten

00:43:22.803 --> 00:43:25.783
für Aktien und die kommen aus unterschiedlichen Domänen,

00:43:25.883 --> 00:43:30.183
sitzen woanders, haben ganz einen unterschiedlichen Hintergrund und die also

00:43:30.183 --> 00:43:36.183
dazu zu zwingen, zusammenzuarbeiten, kann schwierig sein, abhängig von der Unternehmenskultur.

00:43:36.183 --> 00:43:41.143
Und wenn ich jetzt sage, naja, den Change, den bringe ich nicht durch oder diesen

00:43:41.143 --> 00:43:42.463
organisatorischen Change,

00:43:42.743 --> 00:43:47.923
den will ich gar nicht auf mich nehmen, weil ich dann meine ganze Energie dafür

00:43:47.923 --> 00:43:52.903
verbrate und nicht für das, was ich eigentlich machen soll, dann machen Microfrontends

00:43:52.903 --> 00:43:55.283
auch schon bei zwei, drei Teams hin.

00:43:55.283 --> 00:44:00.863
Also bei der Anzahl von kleinen Teams hängt es ganz, ganz stark von der Unternehmenskultur ab.

00:44:01.103 --> 00:44:09.163
Umso mehr Teams es werden, umso eher sollte man zumindest ernsthaft über Microfrontends nachdenken.

00:44:10.483 --> 00:44:15.563
Okay, ich hätte jetzt nicht mit zwei gerechnet, aber so wie du das erklärst, macht das schon Sinn.

00:44:15.603 --> 00:44:17.983
Das Delta kann ja im Prinzip beliebig groß werden zwischen dem,

00:44:18.023 --> 00:44:23.223
was zwei Teams für den richtigen Weg halten und die zu isolieren ist dann wahrscheinlich

00:44:23.223 --> 00:44:24.923
irgendwann einfacher, als sie zusammenzubringen.

00:44:25.283 --> 00:44:29.683
Ja, genau. Also es ist tatsächlich die Unternehmenskultur, beides funktioniert

00:44:29.683 --> 00:44:35.043
und ich habe lustigerweise auch Kunden in ähnlichen Branchen,

00:44:35.083 --> 00:44:37.543
die zu unterschiedlichen Schlüssen kommen.

00:44:37.703 --> 00:44:40.603
Die einen sagen, bei uns klappt es so besser, die anderen sagen,

00:44:40.783 --> 00:44:45.443
aufgrund unserer Unternehmenskultur, aufgrund dessen, was wir an Change durchbringen

00:44:45.443 --> 00:44:48.063
oder nicht, funktioniert ganz eine andere Lösung besser.

00:44:50.231 --> 00:44:55.671
Hm, das ist faszinierend. Ja, aber Menschen sind der Mensch.

00:44:57.171 --> 00:45:00.571
Ja, und das ist ja auch ganz sinnvoll und wie ich finde ja sehr erfrischend

00:45:00.571 --> 00:45:04.851
zu hören, dass man da tatsächlich mal, also von dir habe ich jetzt nicht weniger

00:45:04.851 --> 00:45:06.671
erwartet, aber ich meine so, wenn ich das vergleiche mit dem,

00:45:06.711 --> 00:45:07.611
was ich so im Internet lese,

00:45:08.491 --> 00:45:11.411
dass man da tatsächlich das mal in Betracht zieht und sagt, meine Güte,

00:45:11.531 --> 00:45:14.711
je nachdem wie es ist, muss man es mal so und mal so machen.

00:45:15.351 --> 00:45:18.731
Perfekt wird es eh nicht, aber vielleicht wird es halt einfach irgendwie gut,

00:45:18.731 --> 00:45:23.591
Gut, überlebensfähig, refactorbar natürlich auch, sodass es besser werden kann.

00:45:24.231 --> 00:45:29.311
Ja, genau. Also das Perfekte ist der Feind vom Guten. Ja.

00:45:32.311 --> 00:45:36.931
Okay, dann habe ich jetzt sozusagen noch eine Frage, so aus meiner Angular-Fernperspektive.

00:45:37.251 --> 00:45:41.151
Nehmen wir mal an, wir haben das Szenario lange, haben wir gewerkelt mit unserem

00:45:41.151 --> 00:45:42.611
Monorepo und es war alles supi.

00:45:43.371 --> 00:45:46.751
Und jetzt irgendwann kommt sozusagen der Moment, wo wir sagen,

00:45:46.891 --> 00:45:48.091
es funktioniert nicht mehr.

00:45:48.931 --> 00:45:52.371
Die Leute von Angular Architects haben uns gesagt, jetzt sollten wir mal über

00:45:52.371 --> 00:45:53.531
Microfrontends nachdenken.

00:45:53.751 --> 00:46:00.191
Wie ist so der Weg vom Angular Monolithen zur Microfrontend-Architektur? Wie beschreite ich den?

00:46:00.531 --> 00:46:04.611
Ja, also ich finde diese Vorgehensweise gar nicht schlecht, vor allem dann,

00:46:04.731 --> 00:46:09.971
wenn ich mir am Beginn noch nicht sicher bin, ob sich die Kosten von Microfrontends

00:46:09.971 --> 00:46:13.631
lohnen, die technischen Kosten, die organisatorischen Kosten.

00:46:13.791 --> 00:46:18.551
Dann lieber mal mit einer simplen Architektur starten, Wobei simpel ja nicht

00:46:18.551 --> 00:46:19.991
unbedingt naiv heißen muss.

00:46:20.111 --> 00:46:24.971
Ich kann ja trotzdem Maßnahmen ergreifen, damit ich später im Fall des Falles

00:46:24.971 --> 00:46:29.091
auf die komplexere Architektur ohne große Schmerzen wechseln kann.

00:46:29.940 --> 00:46:35.640
Und so eine Maßnahme wäre Linting. Ich kann heutzutage mit Linta sicherstellen,

00:46:35.640 --> 00:46:39.740
dass gewisse Code-Bereiche nicht auf andere Code-Bereiche zugreifen dürfen.

00:46:40.280 --> 00:46:44.520
Und das macht natürlich auch Sinn, weil auch wenn es ein Monorepo ist,

00:46:44.640 --> 00:46:49.120
wenn es eine monolithische Anwendung ist, will ich ja trotzdem meine Silos,

00:46:49.320 --> 00:46:53.160
meine Verticals, meine Subdomänen abbilden und ich will nicht,

00:46:53.200 --> 00:46:54.880
dass die ineinander greifen.

00:46:54.960 --> 00:46:58.000
Ich will die zumindest, soweit es geht, voneinander entkoppeln.

00:46:58.000 --> 00:47:02.800
Also ich würde da leichtgewichtig starten mit Linting und der Linter sagt uns

00:47:02.800 --> 00:47:06.180
dann, nee, du darfst da nicht hingreifen, was bildest du dir ein?

00:47:06.740 --> 00:47:10.720
Also du machst dann irgendwie sowas wie innerhalb deines Monorepos direkt irgendwas

00:47:10.720 --> 00:47:13.940
importieren, statt über den offiziellen Weg zu beschreiten.

00:47:14.440 --> 00:47:20.820
Ja, genau. Genau. Also ich sage zum Beispiel, alles im Ordner Shopping darf

00:47:20.820 --> 00:47:24.520
nicht auf Zeug im Ordner Invoice zugreifen,

00:47:25.360 --> 00:47:30.260
darf allerdings auf Zeug im Ordner Share zugreifen. Ja, okay. Und dann macht es Sinn.

00:47:31.320 --> 00:47:35.780
Genau. Und das Limiting ist einigermaßen leichtgewichtig. Da habe ich nach wie

00:47:35.780 --> 00:47:39.500
vor eine simple Monorepostruktur, eine monolithische Anwendung.

00:47:39.540 --> 00:47:44.540
Wir nutzen unsere Frameworks so, wie sie gedacht sind. Und im besten Fall komme

00:47:44.540 --> 00:47:47.000
ich darauf, dass ich Microfrontends gar nicht brauche.

00:47:47.200 --> 00:47:52.240
Aber allein schon durch das Lending habe ich einen Vorteil, dass das Ding langfristig wartbar bleibt.

00:47:52.400 --> 00:47:55.380
Und wenn ich darauf komme, jawohl, ich will diesen Schritt gehen,

00:47:55.560 --> 00:47:58.840
diese Mehrkosten von Microfrontends, die machen Sinn,

00:47:59.040 --> 00:48:04.660
dann kann ich dadurch, dass das Lending gewisse Abgrenzungen erzwungen hat,

00:48:04.780 --> 00:48:09.300
meine einzelnen Teile aus dem Monolithen in verschiedene Projekte geben.

00:48:11.540 --> 00:48:15.840
Okay, und das heißt, dann wäre der Weg, was sich ja sozusagen ändern würde,

00:48:15.940 --> 00:48:19.860
wäre ja die API-Oberfläche, es wäre ja die Kontaktfläche, die sich ändert,

00:48:19.900 --> 00:48:21.680
wie redet das eine mit dem anderen?

00:48:21.680 --> 00:48:24.800
Das geht halt nicht mehr über den Weg des Monorepos vorher,

00:48:25.000 --> 00:48:29.080
der ja auch dann sozusagen gegardet war durch die Linter, sondern es geht halt

00:48:29.080 --> 00:48:33.600
eben jetzt über einen neuen Weg und das ließe sich ja wahrscheinlich einigermaßen

00:48:33.600 --> 00:48:36.080
gut einfach enumerieren, einmal refactoren, gucken,

00:48:36.240 --> 00:48:40.960
wo sind die Bruchstellen und dann repariert man die und fertig. Ja, genau.

00:48:41.120 --> 00:48:44.620
Und idealerweise habe ich ja eh sehr grob granulare Bruchstellen.

00:48:44.980 --> 00:48:48.580
Also nichts, was sich innerhalb eines Use Cases abspielt.

00:48:48.880 --> 00:48:53.980
Und in diesen Fällen findet dann das Refactoring irgendwo in der Navigation

00:48:53.980 --> 00:48:59.800
statt, wo ich sage, ab dem Menüpunkt hier geht es mit dem System von da drüben weiter. Ja, genau.

00:49:01.340 --> 00:49:05.520
Okay. Hört sich jetzt ja alles wirklich, sagen wir mal, eher einfach an.

00:49:06.500 --> 00:49:10.020
Oder ist so deine Erfahrung, wenn du jetzt sozusagen in ein Projekt neu einreitest,

00:49:10.020 --> 00:49:12.460
du in deiner Beraterrolle und die sagen, Hilfe, wir kommen nicht mehr weiter,

00:49:12.580 --> 00:49:14.840
möglicherweise brauchen wir Microfrontends, guck mal drauf.

00:49:15.040 --> 00:49:19.180
Also wie übel kann man sich die Chance verbauen, das tatsächlich einigermaßen

00:49:19.180 --> 00:49:23.740
einfach zu übersetzen? Ja, also ich glaube, das größte Problem ist,

00:49:23.840 --> 00:49:29.480
dass Leute Microfrontends verwenden, obwohl die Kosten davon nicht gerechtfertigt sind.

00:49:29.800 --> 00:49:33.220
Dann habe ich wirklich ein Problem. Wenn ich vielleicht gar nicht die Ressourcen

00:49:33.220 --> 00:49:34.440
für ein Plattform-Team habe,

00:49:34.560 --> 00:49:39.520
dann bin ich ständig irgendwie am Troubleshooten von irgendwelchen Workarounds

00:49:39.520 --> 00:49:45.660
und das will man natürlich verhindern, weil die Feature-Teams sollen ja Geschäftsnutzen beisteuern.

00:49:46.340 --> 00:49:50.720
Also das ist tatsächlich ein Problem. Ich unterschätze den Aufwand und habe

00:49:50.720 --> 00:49:53.600
vielleicht gar nicht die Ressourcen für ein eigenes Plattform-Deal.

00:49:53.720 --> 00:49:56.240
Okay, dann habe ich mir das ja nicht verbaut, sondern ich habe sozusagen am

00:49:56.240 --> 00:49:58.480
Anfang den zweiten Schritt vor dem ersten getan.

00:49:59.300 --> 00:50:04.260
Ja, genau. Und da kann ich ja auch wieder zurückgehen, weil verschiedene Anwendungen

00:50:04.260 --> 00:50:09.300
in ein Monorepo zu integrieren, ist mitunter einfacher wie ein Monorepo,

00:50:09.340 --> 00:50:12.300
ohne Linting aufzusplitten auf verschiedene Anwendungen.

00:50:13.500 --> 00:50:18.620
Ja, okay, verstehe. Ich kann den Schritt zurück machen. Habe ich auch nicht

00:50:18.620 --> 00:50:20.780
häufig, aber doch ein paar Mal empfohlen.

00:50:21.660 --> 00:50:26.600
Ja, also weil einfach der Hype so groß ist.

00:50:26.740 --> 00:50:29.960
Also das kennt man ja im Frontend wie glaube ich sonst nirgendwo.

00:50:30.320 --> 00:50:33.000
Irgendwer kommt mit einer neuen Idee oder einer neuen Technologie um die Ecke

00:50:33.000 --> 00:50:35.220
und dann sind alle der Meinung, sämtliche Probleme gehen weg,

00:50:35.260 --> 00:50:36.200
wenn wir genau das machen.

00:50:36.860 --> 00:50:40.220
Genau. Also das kommt auch mit dem Microfrontend gerne mal vor.

00:50:40.540 --> 00:50:43.160
Das Gras ist beim Nachbarn immer grüner, genau.

00:50:45.400 --> 00:50:49.780
Naja, stimmt ja auch. Also ich halte das ja für ein so ein großes Problem unserer

00:50:49.780 --> 00:50:53.220
Zunft, dass ja, wenn man es einmal in die Tonne tritt und neu macht,

00:50:53.320 --> 00:50:55.440
meistens ja wirklich besser wird.

00:50:55.580 --> 00:50:58.120
Ja, okay, es gibt so das Second-System-Syndrom, dass es schief geht,

00:50:58.240 --> 00:51:02.780
aber oft genug wird es halt eben besser und dann attribuiert man das irgendwie

00:51:02.780 --> 00:51:06.360
auf die andere Software, die man verwendet, statt dadurch, dass man es zum zweiten

00:51:06.360 --> 00:51:08.080
Mal macht, wo ich einfach meinen würde,

00:51:08.260 --> 00:51:10.820
ja, wenn du es zum zweiten Mal machst, machst du es natürlich besser als beim

00:51:10.820 --> 00:51:13.400
ersten Mal, weil du ja nicht umhinkommst, was gelernt zu haben.

00:51:15.320 --> 00:51:18.800
Also meine Verschwörungstheorie, warum wir im Fronten ständig alles neu schreiben.

00:51:19.800 --> 00:51:24.380
Ja, guter Punkt. Und ein weiterer Punkt ist wahrscheinlich, ich sehe halt bei

00:51:24.380 --> 00:51:27.240
neuen Technologien zuerst mal die Vorteile.

00:51:27.520 --> 00:51:32.000
Und erst wenn ich etwas länger damit arbeite, bekomme ich auch ein Gefühl für

00:51:32.000 --> 00:51:36.980
die Spitzenmesser oder Scharfenmesser, Spitzenkanten, die da herumliegen.

00:51:37.760 --> 00:51:41.400
Und genau deswegen habe ich vorhin gesagt, dass Gras ist beim Nachbarn immer

00:51:41.400 --> 00:51:44.920
grüner. Auf den ersten Blick schaut das alles so super aus, ich weiß aber gar

00:51:44.920 --> 00:51:47.380
nicht, mit welchen anderen Problemen der Nachbar zu kämpfen ist.

00:51:48.431 --> 00:51:51.031
Das stimmt natürlich, weil die ja möglicherweise noch gar nicht bekannt sind.

00:51:51.431 --> 00:51:54.111
Naja, und vielleicht ist es ja wirklich besser geworden.

00:51:54.211 --> 00:51:57.391
Die Frage ist halt dann wieder eine der Abwägung, wie viel besser ist es wirklich

00:51:57.391 --> 00:51:59.611
geworden? Lohnt sich es jetzt, alles anders zu machen?

00:52:00.731 --> 00:52:05.951
Genau. Ein zweiter Aspekt, auf den ich denken sollte, sind Versionskonflikte.

00:52:07.091 --> 00:52:11.931
Es gibt Bereiche, wo ich vielleicht nicht unbedingt drei Angular-Versionen laden möchte.

00:52:12.411 --> 00:52:18.171
Es gibt aber auch Bereiche, wo das komplett okay ist, weil ich eh wiederkehrende

00:52:18.171 --> 00:52:21.211
Benutzer habe, weil wir über eine Business-Anwendung reden,

00:52:21.431 --> 00:52:27.571
weil ich vom Browser-Cache profitiere oder weil eh alles lazy geladen wird, also nicht auf einmal.

00:52:27.851 --> 00:52:32.811
Also das ist auch ein Aspekt, auf den man denken muss, wie kann ich mit Versionskonflikten

00:52:32.811 --> 00:52:37.911
umgehen, beziehungsweise ist es ein Problem, wenn im Konfliktfall verschiedene

00:52:37.911 --> 00:52:39.531
Versionen geladen werden.

00:52:40.291 --> 00:52:44.511
Ja, ich wollte gerade das als nächstes fragen, weil, also Versionskonflikt von

00:52:44.511 --> 00:52:45.631
irgendwie so einer Utility Library,

00:52:46.371 --> 00:52:49.151
Mai ist ja kein Problem, die hat verschiedene Versionen und dann benutzt halt

00:52:49.151 --> 00:52:53.311
Tool A Version 1 und Tool B benutzt Version 2 und das ist halt von der Ladeperformance

00:52:53.311 --> 00:52:55.791
nicht optimal, aber das kann man ja, das ist ja keine Katastrophe,

00:52:55.871 --> 00:52:58.131
da kann man ja irgendwann sagen, okay, bei nächster Gelegenheit gleichen wir

00:52:58.131 --> 00:53:00.331
das an, haben wir ein kleineres Bundle, alles ist tutti,

00:53:00.791 --> 00:53:04.631
aber du hast ja auch so Cross-Funktionalitäts-Dinger, wie jetzt zum Beispiel

00:53:04.631 --> 00:53:09.311
TypeScript, da ist ja das Laden von einer anderen Version schon schon ein bisschen kniffliger, oder?

00:53:10.951 --> 00:53:15.751
Ja und nein. Also auf der einen Seite lade ich halt ein weiteres Bundle in den

00:53:15.751 --> 00:53:18.871
Browser rein. Also technisch gesehen kriegen wir das schon hin.

00:53:19.171 --> 00:53:23.531
Aber wenn ich Pech habe, dann bekriegen sich diese beiden Bundles miteinander.

00:53:24.291 --> 00:53:29.031
Denken wir zum Beispiel an Router in verschiedenen Single-Page-Applications.

00:53:29.211 --> 00:53:32.891
Der Router ist so ein wenig Ludwig der Vierzehnte, oder?

00:53:32.991 --> 00:53:37.811
Der sagt, die Url bin ich. Aber sobald er mehr wie ein Microfrontent geladen

00:53:37.811 --> 00:53:39.831
hat, gehört dem nicht die gesamte URL.

00:53:39.991 --> 00:53:42.931
Das heißt, ich werde irgendwie den Router konfigurieren müssen,

00:53:43.111 --> 00:53:46.071
damit er nur auf bestimmte URL-Segmente hocht.

00:53:46.711 --> 00:53:51.691
Und daneben kann es aber noch weitere Konflikte geben, wie ich habe drei Komponenten

00:53:51.691 --> 00:53:56.651
in der einen Angular-Version, drei weitere Komponenten in der anderen Angular-Version,

00:53:56.671 --> 00:53:59.831
die ich auch gerade auf der gleichen Seite gebootstrapped habe.

00:53:59.831 --> 00:54:04.791
Die wissen nichts voneinander, wollen sich aber gegenseitig aufrufen. Also wie geht man da vor?

00:54:05.111 --> 00:54:08.691
Und da sind wir dann wieder beim Thema Web Components.

00:54:08.871 --> 00:54:13.691
Also wenn ich das Ganze in Web Components rappe, dann ist es eigentlich dem

00:54:13.691 --> 00:54:16.331
Aufrufe egal, was da dahinter steckt.

00:54:16.411 --> 00:54:21.351
Ob das mit Hand geschrieben ist, ob das dieselbe Angular-Version ist,

00:54:21.491 --> 00:54:25.491
ob es eine andere Angular-Version ist, ob es React oder Vue ist.

00:54:25.491 --> 00:54:31.731
Also da hilft dann tatsächlich das Zusammenspiel von Web Components und Federation. Ja.

00:54:33.227 --> 00:54:36.227
Hört sich trotzdem für mich so an, als wäre das erste Mittel der Wahl,

00:54:36.447 --> 00:54:40.727
diese ganzen verschiedenen Angular-Versionen irgendwie in den Griff zu kriegen, oder?

00:54:41.147 --> 00:54:44.387
Wenn ich es schaffe, auf jeden Fall. Also wenn ich es hinkriege,

00:54:44.507 --> 00:54:50.627
dann ist das das Einfachste, weil dann muss ich auch tatsächlich nur eine Angular-Version

00:54:50.627 --> 00:54:55.287
bootstrappen und alles, was ich nachlade, ist dann wie Lazy Loading für Angular. Angola.

00:54:55.807 --> 00:54:59.847
Sobald ich mehrere Angola-Anwendungen habe, auch wenn ich deren Unterschiede

00:54:59.847 --> 00:55:03.947
weg abstrahiere, muss ich die nebeneinander bootstrappen und das ist halt was,

00:55:04.127 --> 00:55:06.447
wo ich ein paar Workarounds brauche.

00:55:06.607 --> 00:55:09.687
Das ist auch was, was niemand offiziell testet. Man kriegt es hin,

00:55:09.767 --> 00:55:12.267
am Ende des Tages ist es ja nur ein JavaScript,

00:55:12.687 --> 00:55:16.627
das man nachlädt, aber der Weg dorthin ist ein wenig steiniger,

00:55:16.727 --> 00:55:22.087
wie wenn ich einfach nur weitere Komponenten in eine einzige Angola-Version reinlege.

00:55:22.687 --> 00:55:26.527
Okay, kannst du mal kurz skizzieren, wie sowas aussähe? Also was ist so diese

00:55:26.527 --> 00:55:29.887
Art von Workaround, die ich jetzt habe, wenn Angular Version A und B nebeneinander

00:55:29.887 --> 00:55:31.807
betreiben muss aus irgendwelchen Gründen?

00:55:32.267 --> 00:55:37.087
Ja, also ein Workaround ist, ich muss das Ganze irgendwie wegabstrahieren.

00:55:37.167 --> 00:55:39.067
Ich muss die Unterschiede wegabstrahieren.

00:55:39.607 --> 00:55:43.527
Manche Leute definieren Interfaces mit einer Start- und Stopp-Methode.

00:55:43.707 --> 00:55:47.927
Ich nehme ganz gern dafür einfach Web Components, weil es halt ein Web-Standard

00:55:47.927 --> 00:55:52.287
ist. und da kümmert sich der Browser auch selber ums Erzeugen und Aufräumen,

00:55:52.387 --> 00:55:57.467
je nachdem, ob ich den Tag hinzufüge oder auch wieder aus dem DOM entferne. Ja.

00:55:58.047 --> 00:55:59.667
Also das ist schon einmal ganz nett.

00:56:00.387 --> 00:56:05.627
Allerdings kann ja der Angular-Router zum Beispiel keine Web-Components anrouten.

00:56:05.647 --> 00:56:09.167
Das heißt, ich brauche wieder irgendwie eine Wrapper-Component,

00:56:09.207 --> 00:56:13.967
die die Web-Component lädt und reingibt ins DOM und später wieder rausnimmt.

00:56:14.728 --> 00:56:20.388
Ein weiterer Workaround ist, ich muss dem Router irgendwie beibringen,

00:56:20.388 --> 00:56:25.848
dass er nur auf bestimmte Urdel-Segmente achten darf und alle anderen ignorieren muss.

00:56:26.508 --> 00:56:31.108
Weil ich ja vielleicht mehrere Single-Page-Applications mit mehreren Routern

00:56:31.108 --> 00:56:33.528
habe. Etwas, was wir ansonsten ja nicht haben.

00:56:34.548 --> 00:56:38.288
Und ein weiterer Workaround wird bald mal wegfallen.

00:56:38.928 --> 00:56:44.488
Angola hat ja Zone.js dabei, das die Change Detection antriggert.

00:56:44.928 --> 00:56:49.748
Und Zone.js verändert ja so ziemlich alle Browser-Objekte.

00:56:49.828 --> 00:56:54.228
Es macht Monkey-Batching, um herauszufinden, dass irgendwo ein Event gelaufen ist.

00:56:54.568 --> 00:56:57.388
Das ist echt freaky. Also ich meine, für alle, die jetzt ja nicht,

00:56:58.108 --> 00:57:00.248
die wirklich immer gerne wissen möchten, wie die Wurst gemacht ist,

00:57:00.268 --> 00:57:02.628
sich das anzuschauen, ist echt freaky.

00:57:02.748 --> 00:57:04.768
Also Wahnsinn.

00:57:05.188 --> 00:57:08.368
Also wie ich das das erste Mal gesehen habe, war ich mir nicht sicher,

00:57:08.448 --> 00:57:11.188
ob das genial oder furchtbar ist.

00:57:11.368 --> 00:57:14.228
Ich bin nach wie vor der Meinung, es ist ein Grenzgänger.

00:57:14.608 --> 00:57:18.008
Irgendwie ist es super, wenn ich herausfinden kann, da ist ein Event-Händler

00:57:18.008 --> 00:57:21.848
gelaufen, weil ja meistens nach Event-Händlern irgendwas passieren muss,

00:57:21.948 --> 00:57:23.148
Datenbindung und so weiter.

00:57:23.408 --> 00:57:27.528
Auf der anderen Seite will ich halt nicht alle Browser-Objekte auf links drehen.

00:57:27.728 --> 00:57:33.508
Und die gute Nachricht ist, das Angular-Team ist der gleichen Meinung und arbeitet

00:57:33.508 --> 00:57:37.088
gerade daran, dass Sonja es optional wird.

00:57:37.408 --> 00:57:40.828
Wahrscheinlich wird es bei Bestandsanwendungen schwierig sein,

00:57:40.908 --> 00:57:47.188
aber in naher Zukunft werden wir neue Anwendungen ohne SoundJS implementieren.

00:57:48.081 --> 00:57:51.661
Ich finde halt nur, Sound.js ist sehr schön, so in der Tradition von Angular.js

00:57:51.661 --> 00:57:56.481
stehend, als sie da diese Service-Variablen aus den Parametern von den Funktionen

00:57:56.481 --> 00:58:01.041
rausgepasst haben, indem sie die Funktion stringifiziert haben und dann Regex drauf gemacht haben.

00:58:01.121 --> 00:58:03.941
Das ist so die gleiche Kategorie von, das können die doch nicht ernsthaft machen.

00:58:04.781 --> 00:58:07.881
Aber sie machen es doch und es funktioniert. Ja, genau.

00:58:08.221 --> 00:58:12.161
Das ist halt sehr schön. Also vielleicht zum Hintergrund, es gibt da zwei Gründe,

00:58:12.161 --> 00:58:13.301
warum man es gemacht hat.

00:58:13.541 --> 00:58:17.721
Ein Grund war, die haben das von Dart gekannt. Da gibt es Mechanismen,

00:58:17.721 --> 00:58:23.341
um herauszufinden, wann Events gelaufen sind und die wollten das einfach nachimplementieren.

00:58:23.561 --> 00:58:28.701
Damals war ja auch noch Dart eine der unterstützten Sprachen für Angular,

00:58:28.921 --> 00:58:30.581
was mittlerweile nicht mehr der Fall ist.

00:58:30.721 --> 00:58:35.041
Das hat man weggeforgt. Das Dart Angular ist mittlerweile ganz was Eigenes,

00:58:35.121 --> 00:58:37.641
was nur Google intern verwendet wird.

00:58:37.641 --> 00:58:43.141
Und das Zweite war die Hoffnung, dass ein Mechanismus, der uns sagt,

00:58:43.181 --> 00:58:49.321
dass Event-Händler gelaufen sind, mittel- bis kurzfristig zum Web-Standard werden,

00:58:49.501 --> 00:58:50.861
was sich nicht bewahrheitet hat.

00:58:51.201 --> 00:58:57.521
Genauso wie wir relativ lang gebraucht haben, bis Dekoratoren zum Web-Standard geworden sind.

00:58:57.621 --> 00:59:03.581
Und dann haben die erst etwas anders ausgeschaut, wie es das Angular-Team vorausgesagt hat. Ja, genau.

00:59:03.941 --> 00:59:08.621
Aus der Motivation heraus hat man damals so ein GS gebaut und ja,

00:59:08.701 --> 00:59:14.301
das hinkt uns bis heute nach und insofern bin ich auch nicht traurig darüber,

00:59:14.501 --> 00:59:19.121
dass das jetzt da zumindest für neue Anwendungen rausfällt, auch wenn es in

00:59:19.121 --> 00:59:24.501
der Vergangenheit in 95, 97 Prozent der Fälle gute Arbeit geleistet hat.

00:59:24.821 --> 00:59:27.801
Ja, das ist halt ein Arbeitspferd, ne?

00:59:28.601 --> 00:59:34.301
Ja, genau. Schau nie in die Wurstfabrik. Du hast ja gerade die Metapher verwendet.

00:59:34.421 --> 00:59:37.241
Schau nie in die Wurstfabrik, danach bist du Vegetarier.

00:59:37.541 --> 00:59:40.441
Ähnlich ist es wahrscheinlich hier. Ja, aber gut.

00:59:40.921 --> 00:59:44.921
Also das heißt dann aber trotzdem ist es so, obwohl dann mit diesen Microfrontends

00:59:44.921 --> 00:59:49.201
tatsächlich so Dinge, die ja relativ fundamental sind, wie verschiedene Angular-Versionen

00:59:49.201 --> 00:59:50.421
nebenher existieren zu lassen...

00:59:51.880 --> 00:59:55.040
Es wäre nicht schlecht, wenn alle versuchen würden, irgendwie einigermaßen nah

00:59:55.040 --> 00:59:56.760
dran zu bleiben an dem aktuellen Stand.

00:59:57.000 --> 01:00:00.760
Ist ja ohnehin nicht verkehrt, aber die Motivation geht halt hier auch nicht weg.

01:00:01.960 --> 01:00:06.140
Ja, genau. Jetzt hast du vorhin diesen Router angesprochen. Ich kenne mich ja in Angular nicht so aus.

01:00:06.440 --> 01:00:09.100
Ich habe ja früher mal die ein oder andere Zeile React geschrieben.

01:00:09.320 --> 01:00:12.720
Da ist das ja so, sagen wir mal, weniger top-down, weniger geordnet.

01:00:12.840 --> 01:00:16.760
Da ist es ja so, von allem gibt es 27 Implementierungen, die alle inkompatibel zu allem sind.

01:00:17.000 --> 01:00:20.020
Und da ist ja so dieses Busfaktor-Problem sehr viel, sagen wir mal,

01:00:20.020 --> 01:00:24.380
größer und die architekturelle Varianz immer sehr viel größer.

01:00:24.400 --> 01:00:26.400
Ich habe immer das Gefühl, wenn ich eine Angular-Applikation aufmache,

01:00:26.480 --> 01:00:29.880
obwohl ich mich darin nicht auskenne, weiß ich immer, wo alles ist und bei React

01:00:29.880 --> 01:00:31.720
muss ich erstmal irgendwie mich orientieren.

01:00:31.920 --> 01:00:34.360
Welches State-Management verwenden die? Wie haben die das organisiert?

01:00:34.620 --> 01:00:36.720
Server-Side-Rendering? Ja, nein, vielleicht. Wenn ja, wie?

01:00:37.340 --> 01:00:40.980
Das ist alles ein bisschen chaotischer. Aber wie ist das wirklich so mit dieser

01:00:40.980 --> 01:00:43.380
Router-Kompatibilität, die du angesprochen hast?

01:00:43.440 --> 01:00:45.300
Also wo du gesagt hast, der Router muss so konfiguriert werden,

01:00:45.460 --> 01:00:49.900
dass er sich nur einen Teil von der URL anguckt. Jetzt gehe ich mal davon aus,

01:00:49.980 --> 01:00:54.380
bei sowas wie Angular gibt es den Router mitgeliefert, der ist dabei und der kann das.

01:00:54.420 --> 01:00:57.160
Das ist jetzt nicht irgendwie so ein Plugin, das du dir von Max Mütze irgendwo

01:00:57.160 --> 01:00:57.940
her installieren musst.

01:00:59.220 --> 01:01:02.920
Es gibt aber wahrscheinlich trotzdem irgendwie so die populären Angular Add-ons,

01:01:02.920 --> 01:01:04.980
die sich Kreti und Pleti tatsächlich installieren.

01:01:05.500 --> 01:01:07.940
Und da kann ich mir tatsächlich vorstellen, dass viele von denen ja auch nicht

01:01:07.940 --> 01:01:12.900
so auf diesen Microfrontend-Kontext aufgehört, dass die dafür auch vorbereitet sind.

01:01:13.060 --> 01:01:17.520
Also die Frage ist, den Router kannst du einfach so konfigurieren und ihm sagen, guck du auf diesen Teil.

01:01:18.060 --> 01:01:22.900
Des für dich relevanten Bereichs. Ist es häufig so, dass du irgendwelche populären

01:01:22.900 --> 01:01:25.820
Add-ons hast, die aus irgendwelchen Gründen nicht,

01:01:26.300 --> 01:01:28.940
Microfrontend-kompatibel sind, weil die einfach davon ausgehen,

01:01:29.020 --> 01:01:32.200
dass alles monolithisch ist und dass sie jetzt die Kontrolle über einen bestimmten

01:01:32.200 --> 01:01:35.480
Aspekt des Vorgehens haben? Gibt's sowas?

01:01:36.622 --> 01:01:41.462
Ja, aber weniger beim Router. Da wird mehr oder weniger alles mitgeliefert vom

01:01:41.462 --> 01:01:45.882
Angular-Team, beziehungsweise kann ich mich dann da mit Funktionen reinhängen,

01:01:45.902 --> 01:01:49.822
die dann wirklich nur auf die Urdel-Segmente achten, die jetzt relevant sind.

01:01:50.282 --> 01:01:54.222
Ja, okay. Wie gesagt, ich habe es ja auch schon gesagt, obwohl sie das nicht

01:01:54.222 --> 01:01:57.542
offiziell unterstützen, haben sie ja vorbereitende Maßnahmen da drin und haben

01:01:57.542 --> 01:02:02.202
ja sozusagen im Hinterkopf, dass sowas wie eure Module Federation existiert

01:02:02.202 --> 01:02:03.022
und deswegen machen die das.

01:02:03.122 --> 01:02:07.522
Aber das gilt halt eben nicht für, Monsieur, ich baue mal eben ein Open-Source-Paket

01:02:07.522 --> 01:02:10.842
und schmeiße es auf GitHub. Hoppla, plötzlich nutzen das alle.

01:02:11.442 --> 01:02:15.682
Ich meine, sowas passiert ja, ne? Ja, genau. Also das größte Problem an der

01:02:15.682 --> 01:02:20.582
Stelle sind tatsächlich die alten, älteren NBM-Pakete.

01:02:21.202 --> 01:02:27.842
NBM-Pakete, die vielleicht noch auf Code fußen, der auf ECMAScript 5 basiert.

01:02:27.842 --> 01:02:33.442
Das klingt jetzt komisch, aber wir finden sowas ganz, ganz häufig bei riesengroßen,

01:02:33.442 --> 01:02:38.222
bekannten Widget-Anbietern, Kontroll-Dual-Kit-Anbietern.

01:02:38.262 --> 01:02:41.702
Die haben irgendwie alten Code da drinnen, das ist vielleicht sogar noch tatsächlich

01:02:41.702 --> 01:02:45.222
ECMAScript 5 und haben halt die ganze Zeit drüber gerappt.

01:02:45.222 --> 01:02:49.242
Da gibt es irgendwie einen lieben React-Rapper und einen lieben Angular-Rapper

01:02:49.242 --> 01:02:53.822
und in dem Fall kann es vorkommen, je nachdem wie das gebaut ist,

01:02:54.322 --> 01:02:58.762
dass Federation zwar den Rapper erkennt, aber nicht mehr erkennt,

01:02:58.822 --> 01:03:04.382
dass der Rapper eigentlich darunter auf ECMAScript 5 zugreift und da irgendwelche

01:03:04.382 --> 01:03:07.762
Sachen macht, die beim Teilen auch berücksichtigt werden müssen.

01:03:07.922 --> 01:03:10.642
Und ja, dann haben wir halt Probleme mit dem Teilen.

01:03:11.082 --> 01:03:13.202
Achso, also die haben dann so globale Nebenwirkungen.

01:03:13.962 --> 01:03:17.862
Ja, genau. Globale Nebenwirkungen, genau. Seiteneffekte, genau. Ja, okay.

01:03:18.906 --> 01:03:21.226
Okay, aber das kommt schon vor. Ja, okay. Ich hätte auch erwartet,

01:03:21.246 --> 01:03:23.606
dass so Widget-Sammlungen da das größte Ding sind.

01:03:23.886 --> 01:03:27.486
Ja, also umso länger die Historie, umso eher die Wahrscheinlichkeit.

01:03:27.886 --> 01:03:32.626
Die, die erst vor kurzem begonnen haben oder die, die vielleicht erst beginnend

01:03:32.626 --> 01:03:36.726
mit Angular ihr Widget-Toolkit aufgebaut haben, da hat man das Problem weniger.

01:03:36.906 --> 01:03:38.886
Auch Angular Material, das ist mit

01:03:38.886 --> 01:03:42.246
Angular mitgewachsen, basiert voll auf Angular, da gibt es keine Legacy.

01:03:42.246 --> 01:03:48.046
Aber bei Zeug, das vielleicht schon 20 Jahre umher schwirrt und immer nur gerappt

01:03:48.046 --> 01:03:52.006
worden ist, ja, da haben wir tatsächlich genau das Problem. Okay.

01:03:53.126 --> 01:03:58.366
Reagieren die dann auf Bug-Reports oder gilt sowas wie Module Federation und

01:03:58.366 --> 01:04:02.906
Microfrontends als so obskurer, nebensächlicher Use-Case? Den braucht eh keiner.

01:04:04.026 --> 01:04:09.366
Naja, die kann man dann selten dazu bewegen, beziehungsweise wäre es auch häufig

01:04:09.366 --> 01:04:13.046
ziemlich aufwendig, dass die dann intern alles umschreiben.

01:04:13.166 --> 01:04:16.226
Die wollen ja auch verschiedene Plattformen bedienen, also React,

01:04:16.506 --> 01:04:19.086
Vue, Angular und so weiter. dann.

01:04:19.126 --> 01:04:22.506
Und man merkt, die anderen machen doch auch Microfrontends, oder?

01:04:22.866 --> 01:04:24.726
Also Microfrontend kann ich auch mit React bauen.

01:04:25.206 --> 01:04:30.666
Ja, total, total. Aber es ist halt alter Code und ja, häufig ist halt dann der

01:04:30.666 --> 01:04:34.986
Anreiz nicht groß genug, das zu refactoren oder komplett zu refactoren.

01:04:35.106 --> 01:04:38.906
Gibt auch Fälle, wo man sieht, ja, gewisse Teile sind refactored,

01:04:39.026 --> 01:04:43.426
aber die aufwendigen Teile, das Data-Gerät, das alles Mögliche kann,

01:04:43.526 --> 01:04:45.486
ist nach wie vor ECMAScript 5.

01:04:45.946 --> 01:04:48.866
Und dann wird es schwierig, merkt man auch beim Tree-Shaking,

01:04:49.006 --> 01:04:53.246
dass dann plötzlich Tree-Shaking nicht mehr funktioniert, unabhängig von Microfrontends,

01:04:53.406 --> 01:04:57.286
weil ich halt ECMAScript 5 nicht so wirklich gut Tree-Shaken kann.

01:04:57.626 --> 01:05:02.786
Ja, aber was machst du denn, wenn du jetzt wirklich so ein Ding mit globalen Nebenwirkungen hast?

01:05:04.142 --> 01:05:07.162
Ja, entweder trickst man herum,

01:05:07.382 --> 01:05:12.282
dass man sagt, ja, ich schaffe es, dass ich da dann die globale Variable anders benenne,

01:05:12.402 --> 01:05:16.082
keine Ahnung, hier X und dort Y und dann sage ich dem Wrapper,

01:05:16.162 --> 01:05:22.422
du greif auf X zu, du greif auf Y zu oder ich scheide tatsächlich gewisse Libraries

01:05:22.422 --> 01:05:25.842
bereits in der Evaluierungsphase aus.

01:05:25.842 --> 01:05:28.982
Häufig beginnt man ja mit einem Proof of Concept,

01:05:29.162 --> 01:05:31.762
wenn man sowas macht und dann stellt man vielleicht schon fest,

01:05:31.922 --> 01:05:38.322
naja, dieses Paket hier ist doch nicht das gelbe vom Ei und vielleicht stellt man dann aber auch fest,

01:05:38.462 --> 01:05:41.862
ja, aber eigentlich haben wir das eh nicht so richtig gemocht,

01:05:41.882 --> 01:05:44.342
weil es auch an anderen Stellen Probleme gemacht hat,

01:05:44.542 --> 01:05:48.542
Tree Shaking wie angemerkt und dann sucht man sich was anderes.

01:05:48.542 --> 01:05:55.022
Eine gute Nachricht ist auch, dass immer mehr Firmen weggehen von diesen Standard-Bibliotheken

01:05:55.022 --> 01:05:57.562
und sich ihr eigenes Design-System schreiben,

01:05:57.862 --> 01:06:00.982
auch weil wir eine gewisse Marke nach draußen tragen müssen,

01:06:01.162 --> 01:06:05.042
beziehungsweise weil die halt ihre Widgets,

01:06:05.422 --> 01:06:11.022
die sie immer und immer wieder brauchen, in verschiedenen Anwendungen gleichgestalten möchten.

01:06:11.742 --> 01:06:13.942
Und wahrscheinlich ist es ja auch nicht die allerschlechteste Idee,

01:06:14.042 --> 01:06:17.742
die unmittelbare Kontaktstelle zur Kundschaft nicht auszusourcen,

01:06:17.822 --> 01:06:19.802
sondern im Haus unter Kontrolle zu haben.

01:06:20.522 --> 01:06:23.222
Ja, genau. Und da sind wir wieder beim Thema Plattform-Team.

01:06:23.462 --> 01:06:27.702
Ich habe festgestellt, da reichen häufig weniger als eine Handvoll Leute,

01:06:27.922 --> 01:06:34.522
die für ganz, ganz viele Teams, mehrere Dutzend Teams eben, unter anderem diese Design-Systeme bauen.

01:06:35.542 --> 01:06:38.342
Ja, ich meine, das ist das Gleiche wie mit dem Plattform-Team.

01:06:38.382 --> 01:06:41.142
Das hast du genau richtig gesagt. gesagt, wenn du es nicht explizit machst,

01:06:41.302 --> 01:06:44.902
passiert es trotzdem, aber halt auf eine garantiert suboptimale Weise.

01:06:45.542 --> 01:06:49.622
Ja, genau. Wenn halt niemand ein Designsystem macht und man hat nicht tatsächlich

01:06:49.622 --> 01:06:53.462
wirklich irgendwie sich ein Budgetding eingekauft und verwendet das 1 zu 1 so

01:06:53.462 --> 01:06:55.002
wie dies ausliefert, ohne Anpassung,

01:06:55.822 --> 01:06:59.802
was jetzt meiner Erfahrung nach nie passiert, weil dann passiert es trotzdem,

01:06:59.882 --> 01:07:03.102
dann hast du ein Designsystem, aber halt eben implizit und dokumentiert.

01:07:03.302 --> 01:07:06.022
Keiner ist wirklich zuständig und hinterher stehst du da und wunderst dich.

01:07:06.122 --> 01:07:07.662
Das muss man tatsächlich explizit machen.

01:07:08.302 --> 01:07:12.602
Schlechte UI, schlechte UX, schlechte Accessibility, weil der,

01:07:12.702 --> 01:07:16.582
der es gebaut hat, es halt nur für einen Use Case gebraucht hat und schnell

01:07:16.582 --> 01:07:22.782
den Use Case fertig machen wollte, anstatt dass er ein Widget mit entsprechender Qualität baut.

01:07:23.282 --> 01:07:25.842
Ja klar, weil es gibt ja kein Budget, ist ja nicht sein Job,

01:07:25.842 --> 01:07:27.842
er hat ja was eigentlich anderes zu tun. Ja, genau.

01:07:28.022 --> 01:07:34.742
Er ist ja Anwendungsentwickler, er oder sie, und die sollen ja Geschäftsnutzen bieten. Genau.

01:07:34.782 --> 01:07:36.982
Und nicht Infrastruktur, weil brauchen wir nicht, haben wir schon.

01:07:37.082 --> 01:07:39.002
Hält schon. Wird schon gut gehen.

01:07:41.022 --> 01:07:45.082
Okay, was habe ich vergessen über Module Federation zu fragen?

01:07:46.453 --> 01:07:49.633
Als alter Hecht stellt man sich die Frage, wo ist der Haken?

01:07:50.633 --> 01:07:55.013
Und viele Haken haben wir ja schon besprochen. Aber ein Haken,

01:07:55.053 --> 01:08:01.453
den wir noch nicht besprochen haben, ist, ursprünglich ist Module Federation an Webpack gehangen.

01:08:01.713 --> 01:08:07.353
Und Webpack war vielleicht noch vor fünf Jahren das Ding, das man einfach verwendet hat.

01:08:07.453 --> 01:08:13.633
Aber mittlerweile nutzt man eher andere Sachen. Da gibt es neuere Bundler,

01:08:13.653 --> 01:08:16.453
die moderner sind, die um einige schneller sind.

01:08:16.993 --> 01:08:20.333
Faktor 2 bis 4 ist da häufig möglich.

01:08:20.713 --> 01:08:25.493
In Benchmarks häufig auch mehr, wobei man immer vorsichtig sein muss,

01:08:25.633 --> 01:08:27.893
wenn jemand sagt, ich bin um Faktor

01:08:27.893 --> 01:08:32.013
500 schneller, muss man sich genau anschauen, was hat er da gemacht.

01:08:32.473 --> 01:08:36.593
Ja, ich denke halt aber tatsächlich, also gerade so der Performance-Faktor,

01:08:36.593 --> 01:08:39.473
wenn die Leute sagen, irgendwie Webpack ist irgendwie nervt,

01:08:39.473 --> 01:08:42.053
weil Config-Datei, ich denke halt so, das ist nicht wirklich das Problem.

01:08:42.133 --> 01:08:45.813
Das Problem an Webpack ist tatsächlich, glaube ich, eher, dass diese ganzen

01:08:45.813 --> 01:08:47.533
neuen Tools, die sind ja in Programmiersprachen geschrieben,

01:08:47.693 --> 01:08:51.633
die für den heutigen Computer geschrieben sind, also mit Go und Rust und so,

01:08:51.713 --> 01:08:56.213
die können ja wirklich das nutzen, was du heutzutage auf der Maschine von Entwicklerinnen

01:08:56.213 --> 01:08:57.133
und Entwicklern vorfindest. ist.

01:08:57.533 --> 01:08:59.553
Und mit so einem JavaScript geht das halt eben einfach nicht so gut.

01:08:59.613 --> 01:09:02.853
Also da kann halt auch Webpack nichts für. Das ist halt eben einfach so der Marsch der Zeit.

01:09:02.973 --> 01:09:09.473
Also ja, auch wenn ich als alter Hase von nichts genervt bin,

01:09:09.533 --> 01:09:11.933
mehr genervt bin, als wenn jemand sagt, schmeiß das Ding weg,

01:09:12.013 --> 01:09:13.953
das funktioniert, nimm was Neues, das genau das Gleiche macht.

01:09:14.273 --> 01:09:17.253
An dem Punkt muss man den Leuten einfach recht geben. Das ist schneller und

01:09:17.253 --> 01:09:20.333
das ist auch mehr als nur dieser ich schreib's nochmal und hab dabei was gelernt

01:09:20.333 --> 01:09:22.293
Effekt, sondern das ist tatsächlich ein technischer Fortschritt,

01:09:22.353 --> 01:09:23.133
der sich da manifestiert.

01:09:23.293 --> 01:09:27.293
Also ja, ich nehme heutzutage auch lieber ES-Bild, wenn ich die Wahl habe. Ja, genau.

01:09:27.413 --> 01:09:32.353
Und Build-Performance ist tatsächlich ein großes Problem bei diesen großen Anwendungen,

01:09:32.373 --> 01:09:37.233
wo zig Teams zusammenarbeiten oder wo vielleicht ein Team aus zwölf Leuten besteht,

01:09:37.353 --> 01:09:38.973
die regelmäßig Code erzeugen.

01:09:39.013 --> 01:09:42.813
Also das ist schon ein Thema, das zu Schmerzen führen kann und deswegen verstehe

01:09:42.813 --> 01:09:44.593
ich, dass man in diese Richtung geht.

01:09:44.693 --> 01:09:50.993
ES-Build oder RS-Back oder Roll-Down heißt es, glaube ich, Roll-Down, Roll-Up.

01:09:51.493 --> 01:09:55.453
Roll-Up ist der langsame, Roll-Down ist, glaube ich, der schnelle. Ja, genau.

01:09:56.693 --> 01:09:59.873
Deswegen verstehe ich das auch, ist auch super nachvollziehbar.

01:10:00.273 --> 01:10:03.533
Es ist allerdings die Frage, wie kriegen wir Federation,

01:10:04.033 --> 01:10:10.293
das ursprünglich mit Webpack gekommen ist, auf diese neuen Bundler und als Architekt,

01:10:10.293 --> 01:10:12.753
der mehr als fünf Jahre in die Zukunft schaut,

01:10:12.953 --> 01:10:16.233
muss man sich auch die Frage stellen, wie bekomme ich das Ding dann auf den

01:10:16.233 --> 01:10:21.093
nächsten Bundler, der vielleicht in fünf Jahren mal auf den Markt kommt oder in sieben Jahren.

01:10:21.093 --> 01:10:26.193
Weil wir alle wissen, so ein Stück Enterprise-Software muss meistens mehrere

01:10:26.193 --> 01:10:30.433
Dekaden gewartet werden und Werkzeuge kommen und gehen.

01:10:30.573 --> 01:10:34.153
Das sind meistens, ich weiß nicht, sieben Jahreszyklen. Ich glaube,

01:10:34.293 --> 01:10:39.713
MapBag war jetzt ungefähr sieben Jahre sehr, sehr populär und links und rechts

01:10:39.713 --> 01:10:40.893
flacht die Kurve halt ab.

01:10:41.628 --> 01:10:46.088
Und da haben wir erst zwei Ansätze. Der eine Ansatz ist, wir migrieren es von

01:10:46.088 --> 01:10:49.668
Bundler zu Bundler, was teilweise auch gemacht wird.

01:10:49.748 --> 01:10:58.128
Es gibt mittlerweile eine Implementierung für RS-Back, diesen spirituellen Nachfolger

01:10:58.128 --> 01:11:02.028
von Webpack, der in einer dieser nativen Sprachen geschrieben ist.

01:11:02.688 --> 01:11:07.308
Allerdings ist es halt immer aufwendig, sowas wie Federation auf einen neuen

01:11:07.308 --> 01:11:12.548
Bundler zu migrieren, weil ich habe da die Laufzeitsicht, aber auch die Compile-Time-Sicht

01:11:12.548 --> 01:11:17.368
und die ist halt schwierig zu migrieren und in dem Fall sehr Bundler-abhängig.

01:11:17.388 --> 01:11:22.508
Oder ich versuche, das Ganze auf der Basis von Web-Standards neu zu implementieren

01:11:22.508 --> 01:11:25.408
und genau das ist der Weg, den ich gerade beschreite.

01:11:25.608 --> 01:11:31.388
Ich habe Federation neu implementiert und unter der Motorhaube ist es komplett

01:11:31.388 --> 01:11:36.768
egal, welcher Bundler verwendet wird, solange da ECMAScript-Module rauspurzeln.

01:11:37.888 --> 01:11:42.248
Vorgebundelte ECMAScript-Module, die dann über eine Inboard-Map geladen werden.

01:11:42.568 --> 01:11:47.368
Und die Runtime erzeugt dann dynamisch die Inboard-Map und zwar so,

01:11:47.548 --> 01:11:50.088
dass Versionskonflikte aufgelöst werden.

01:11:50.248 --> 01:11:54.888
Das heißt, aus der Sicht von Entwicklern, Entwicklerinnen, schaut das Ganze

01:11:54.888 --> 01:11:58.368
aus wie immer, schaut das Ganze aus wie Webpack-Module-Federation.

01:11:59.268 --> 01:12:04.548
Aus der Sicht unterhalb der Motorhaube werden da allerdings Inboard-Maps und

01:12:04.548 --> 01:12:07.428
ECMAScript-Module verwendet, also Web-Standards.

01:12:07.528 --> 01:12:13.688
Und somit ist es mir komplett, wirklich komplett egal, welchen Bundle ich verwendet habe.

01:12:14.108 --> 01:12:18.028
ECMAScript-Module werden es hoffentlich alle kennen und können,

01:12:18.108 --> 01:12:20.588
weil es ist ja mittlerweile ein etablierter Standard.

01:12:20.888 --> 01:12:25.448
Und somit habe ich auch kein Problem, wenn ich mal in fünf Jahren woanders hin wechseln möchte.

01:12:26.788 --> 01:12:30.608
Oder ich kann das auch wegwerfen und mir selber schreiben, wenn ich sage,

01:12:30.768 --> 01:12:33.648
na ja, das, was der Steyr gemacht hat, das gefällt mir nicht mehr,

01:12:33.648 --> 01:12:37.828
dann wäre es einfach weg ich schaffe es auch selber irgendwie meine ecken,

01:12:38.720 --> 01:12:43.520
Module raus zu generieren und entsprechende Inboard-Maps zu generieren.

01:12:43.680 --> 01:12:47.240
Ist ein halber Aufwand, vielleicht nicht so super generisch,

01:12:47.280 --> 01:12:50.580
aber ich weiß, ich komme auch ohne Steier

01:12:50.580 --> 01:12:55.200
aus, was vielleicht auch ein Qualitätsmerkmal von einer Library ist.

01:12:55.240 --> 01:12:59.780
Du hast es eh einmal gesagt in einer unserer Diskussionen, wenn man eine Library

01:12:59.780 --> 01:13:04.360
sich einbaut, dann sollte man schon am Beginn sich die Frage stellen,

01:13:04.560 --> 01:13:08.020
wie bekomme ich das wieder los, wie bekomme ich das wieder weg und genau,

01:13:08.160 --> 01:13:11.360
das ist ist da einfach möglich, weil ich Web-Standards habe.

01:13:12.380 --> 01:13:16.720
Ja, man kriegt es halt entweder einfach weg oder der umgekehrte Fall ist natürlich

01:13:16.720 --> 01:13:20.500
auch der, also du hast es jetzt gerade so formuliert, als die Bundler kennen

01:13:20.500 --> 01:13:21.760
hoffentlich Eckenhaus-Skriptmodule.

01:13:22.380 --> 01:13:25.200
Ich würde ja eher darauf setzen, nicht nur kennen die das, sondern alle Bundler,

01:13:25.220 --> 01:13:26.700
die jemals kommen werden, werden das kennen.

01:13:27.220 --> 01:13:29.500
Ja, genau. Einfach nur, weil die Web-Standards halt nicht weggehen.

01:13:29.540 --> 01:13:31.100
Das heißt, da kannst du dich wirklich drauf verlassen.

01:13:31.260 --> 01:13:33.960
Und ja, du wirst immer irgendwelches Gehexe drumherum machen müssen,

01:13:34.060 --> 01:13:35.480
damit sich das irgendwie integriert.

01:13:36.000 --> 01:13:39.880
Aber so die Kernkontaktstellen sind halt mehr oder minder in Stein gemeißelt

01:13:39.880 --> 01:13:41.020
und werden niemals verschwinden.

01:13:41.620 --> 01:13:45.500
Du kannst halt immer noch irgendwie in JavaScript den Blödsinn von 1996 machen.

01:13:45.680 --> 01:13:48.860
Du tust es halt nicht mehr, aber wenn du was für 1996 geschrieben hast,

01:13:49.020 --> 01:13:50.700
dann wird das heutzutage immer noch funktionieren.

01:13:51.900 --> 01:13:55.920
Ausnahme halt HTTPS, aber sonst hält das halt eben alles bis in alle Ewigkeit

01:13:55.920 --> 01:13:58.280
und das ist halt eben, da sprichst du mir aus der Seele.

01:13:59.320 --> 01:14:02.240
Wenn man schon was Aufwendiges baut, sollte man sich halt ein Fundament überlegen,

01:14:02.280 --> 01:14:04.560
dass das halt eben auch ein bisschen was hält.

01:14:05.480 --> 01:14:10.940
Ja, genau. Und darum geht es ja gerade bei Anwendungen, die sich in einer Größe

01:14:10.940 --> 01:14:13.300
bewegen, wo Microfront einen Sinn macht.

01:14:13.540 --> 01:14:18.300
Das sind die Anwendungen, die von mehreren Teams über die Karten hinweg gewartet werden.

01:14:20.660 --> 01:14:25.740
Ja. Und wo ja niemand will, dass das irgendwie in Kürze ersetzt wird.

01:14:27.240 --> 01:14:31.220
Ja, beziehungsweise es kann sich auch keiner leisten, eine Anwendung,

01:14:31.220 --> 01:14:37.480
die von 10 Teams 10 Jahre lang gebaut worden ist, von heute auf morgen komplett abzulösen. Ja.

01:14:38.780 --> 01:14:44.360
Aber weißt du, jetzt sitzen wir hier abends gemütlich rum und erzählen uns so,

01:14:44.440 --> 01:14:45.880
wie man dazu mit dem Frontend machen möchte.

01:14:45.940 --> 01:14:48.720
Vor ein paar Wochen saß ich mit jemand anders, ich weiß, dass du diesen Podcast

01:14:48.720 --> 01:14:52.460
hörst, der wird sich jetzt da angesprochen fühlen, bei Bierchen und der erzählte

01:14:52.460 --> 01:14:55.700
mir, wie er halt eben eine Enterprise-Frontend-Anwendung bauen muss,

01:14:55.840 --> 01:15:00.600
in seinem Job, in seinem Rahmen da als Consultant und die bauen halt irgendwie

01:15:00.600 --> 01:15:02.360
so ihr ganzes Zeug da auf diesem,

01:15:03.180 --> 01:15:05.780
auf so Sachen wie Next.js und so auf. Mhm.

01:15:07.300 --> 01:15:11.300
Was funktioniert und so, aber wo halt tatsächlich so die Stabilitätsfrage etwas

01:15:11.300 --> 01:15:13.680
im Raume steht, wenn man halt mal drüber nachdenkt allein.

01:15:15.171 --> 01:15:19.671
Das findet halt da nicht so ganz statt. Man kann ja modernen Krempel verwenden,

01:15:19.691 --> 01:15:21.451
man kann ja irgendwie die neueste Angular-Version einsetzen,

01:15:21.491 --> 01:15:22.531
aber die Frage ist halt immer so,

01:15:23.851 --> 01:15:27.691
was sind die Dinger, was sind wirklich diese Dinger, die du in den Brunnen treibst,

01:15:27.771 --> 01:15:30.711
auf denen das Fundament halt eben beruht und wie stabil kann das wirklich sein?

01:15:31.991 --> 01:15:35.631
Und da sind wir dann wieder beim Thema ernsthafte Architekturarbeit,

01:15:35.831 --> 01:15:39.971
wo ich halt in Trade ausdenken muss und mir überlegen muss, auf welcher Seite

01:15:39.971 --> 01:15:42.691
sind die Schmerzen wahrscheinlich geringer.

01:15:42.691 --> 01:15:46.411
Ganz genau wissen tut man es eh nicht, Aber es sollte zumindest eine bewusste

01:15:46.411 --> 01:15:51.751
Entscheidung sein, dass ich die oder die Variante wähle, den oder den Weg einschlage,

01:15:51.811 --> 01:15:56.311
weil ich mehr davon die oder die Vorteile oder auch nur weniger Schmerzen erhoffe.

01:15:56.311 --> 01:15:59.471
Ja, und das halt eben das Bewusstmachen ist, glaube ich, das Wichtigste,

01:15:59.471 --> 01:16:02.691
dass du wirklich immer so das als Risikokalkulation auch verstehst.

01:16:02.911 --> 01:16:06.211
So, das ist die wahrscheinlichste Variante, die am wahrscheinlichsten uns dieses

01:16:06.211 --> 01:16:08.851
und jenes Problem, aber auch diese und jene Abhilfe schafft.

01:16:08.931 --> 01:16:11.891
Also setzen wir mal drauf und wenn man es halt eben so geframed hat,

01:16:11.931 --> 01:16:14.931
kann man es hinterher ja auch evaluieren und kann sagen, wir haben das entschieden

01:16:14.931 --> 01:16:15.891
auf dieser und jener Basis.

01:16:16.351 --> 01:16:18.791
Hat es das gebracht? Ja, nein, vielleicht. Und dann kann man ja überlegen,

01:16:18.811 --> 01:16:19.591
was sind die nächsten Schritte?

01:16:20.231 --> 01:16:25.591
Ja, genau. Das ist auch so ein wenig mein Beratungsansatz. Ich bin nicht jemand,

01:16:25.731 --> 01:16:30.571
der sagt, macht genau das und macht niemals das, sondern mir geht es darum,

01:16:30.711 --> 01:16:33.131
den Leuten die Konsequenzen bewusst zu machen.

01:16:33.291 --> 01:16:38.011
Seid euch bewusst, dass das und das passieren kann mit der und der Wahrscheinlichkeit.

01:16:39.747 --> 01:16:42.207
So sollten es alle machen. Erst denken, dann tippen.

01:16:44.987 --> 01:16:48.867
Okay. Dann würde ich sagen, wenn wir jetzt also den Haken am Ganzen,

01:16:48.887 --> 01:16:52.767
die Build-Performance besprochen haben und wir auch schon geklärt haben,

01:16:52.847 --> 01:16:57.047
wie wir es regeln, nämlich indem Module-Federation fit gemacht wird für alles,

01:16:57.107 --> 01:16:59.487
was da auch immer kommen mag, durch das Setzen auf Web-Standards.

01:17:00.207 --> 01:17:02.027
Würde ich sagen, machen wir doch einen Deckel drauf, oder?

01:17:02.587 --> 01:17:05.307
Ich glaube, das ist jetzt eine ganz runde Sache geworden, genau.

01:17:05.827 --> 01:17:08.627
Okay. Wenn ich Module-Federation machen möchte, ich sitze jetzt hier an meinem

01:17:08.627 --> 01:17:11.707
Angular-Monolithen, Ich höre jetzt diesen Podcast und stelle fest,

01:17:11.827 --> 01:17:15.027
so, das klingt alles ganz vernünftig, Microfrontend wäre mal was,

01:17:15.027 --> 01:17:16.027
worüber wir nachdenken müssten.

01:17:16.747 --> 01:17:20.567
Angular Architects IO, man schreibt dich an, man kriegt die Beratung,

01:17:20.647 --> 01:17:21.687
so funktioniert es, oder?

01:17:22.387 --> 01:17:26.447
Ja, genau, so funktioniert es. Es gibt eine Kontaktformule auf der Website und

01:17:26.447 --> 01:17:30.027
dann können wir uns noch überlegen, ob wir das Ganze projektbezogen machen,

01:17:30.227 --> 01:17:35.467
also auf der Basis vom bestehenden Code ein wenig prototypen und aufzeigen,

01:17:35.467 --> 01:17:40.187
welche Möglichkeiten es gibt oder ob man das lieber im Schulungssetting hätte

01:17:40.187 --> 01:17:41.927
oder vielleicht auch beides.

01:17:42.067 --> 01:17:45.727
Da gibt es die verschiedensten Anforderungen, aber das ist so,

01:17:45.767 --> 01:17:47.107
wie wir typischerweise vorgehen.

01:17:47.247 --> 01:17:51.867
Und in der Regel sind das dann Workshops, die dauern drei Tage,

01:17:52.007 --> 01:17:58.467
zwei bis drei Tage, wo man entweder mit dem Code des Kundens arbeitet oder Trockenschwimmen

01:17:58.467 --> 01:17:59.827
in einem Training macht.

01:17:59.827 --> 01:18:05.667
Und danach haben die Leute dann das Rüstzeug, um loszulegen.

01:18:05.747 --> 01:18:07.707
Uns geht es nicht darum, die Kunden zu binden.

01:18:07.847 --> 01:18:12.107
Wir freuen uns natürlich, wenn die Kunden dann nach vier Monaten wiederkommen

01:18:12.107 --> 01:18:14.127
und sagen, schaut mal drüber für einen Tag.

01:18:14.327 --> 01:18:16.747
Aber es ist so ungefähr der Rahmen, wo sich das Ganze entwickelt.

01:18:18.873 --> 01:18:22.593
Okay, gut. Dann würde ich sagen, machen wir doch einen Deckel drauf.

01:18:22.813 --> 01:18:26.613
Manfred, es war mir ein Vergnügen, dich endlich mal in den Podcast eingefangen zu haben.

01:18:27.113 --> 01:18:30.473
Ja, vielen Dank fürs Einladen. Ja, es ist unglaublich, wie oft man zusammen

01:18:30.473 --> 01:18:33.313
frühstücken kann, aber nie auf den Gedanken kommt, man möge doch mal dieses

01:18:33.313 --> 01:18:35.353
Gespräch einfach mal aufnehmen.

01:18:36.373 --> 01:18:39.033
Jetzt haben wir es endlich mal hinbekommen. Jetzt haben wir es geschafft,

01:18:39.233 --> 01:18:44.313
genau. Super. Dann danke, dass du da warst und uns erleuchtet hast über die Module Federation.

01:18:45.293 --> 01:18:48.493
Wir danken der Wertenhörerschaft, außerdem fürs Zuhören.

01:18:48.673 --> 01:18:52.833
Ihr wisst Bescheid, wo ihr uns findet, auf Social Media und dass wir einen Community-Slack haben.

01:18:52.973 --> 01:18:59.313
Nicht vergessen, in Manfred anzuheuern, angulararchitects.io und ja, danke fürs Zuhören.

01:18:59.373 --> 01:19:03.893
Ich habe im Moment keine Kenntnis darüber, was die nächste Revision enthält. Lass mal kurz gucken.

01:19:04.113 --> 01:19:08.633
Ach doch, Manfred, der Wanderzirkus geht weiter. Nächste Revision ist offenbar

01:19:08.633 --> 01:19:11.633
mit Hans-Christian Otto zum Thema Server-Site-Rendering.

01:19:12.433 --> 01:19:16.633
Schöne Grüße. Werde ich ausrichten. Ja, ich habe das, was ich mit dir gemacht

01:19:16.633 --> 01:19:19.393
habe, ein paar Mal mehr gemacht, nämlich, ah, ich frühstücke gerade mit diesem

01:19:19.393 --> 01:19:22.293
Typen, der schlaue Dinge zu erzählen hat. Lass mal den Podcast eintüten.

01:19:23.473 --> 01:19:27.153
Und ich habe gedacht, ich bin der Einzige. Äh, nein, nein, nein, nein, nein.

01:19:27.233 --> 01:19:30.393
Ich habe da, ich habe, alle, alle, die du kennst, alle, an die du jetzt gerade

01:19:30.393 --> 01:19:33.773
denkst, die werden hier jetzt alle in den nächsten Wochen aufschlagen und uns was erzählen.

01:19:34.593 --> 01:19:37.793
Super. Sehr gut. Alles klar. Manfred, vielen, vielen Dank.

01:19:37.953 --> 01:19:40.553
Ich wünsche dir noch einen schönen Abend. Ich wünsche der Hörerschaft noch einen

01:19:40.553 --> 01:19:42.373
schönen Tag oder schönen Abend oder schönen Morgen.

01:19:42.533 --> 01:19:46.273
Danke fürs Zuhören und bis zum nächsten Mal. Tschüsschen. Danke. Ciao.

01:19:46.480 --> 01:20:09.680
Music.

01:19:47.233 --> 01:20:00.113
Bis zum nächsten Mal.