Mirko Hillert: Auf den JavaScript Days hast du den Speaker Panel zum Thema Micro Frontends moderiert. Was genau sind Micro Frontends?
Hans-Christian Otto: Ein spannendes Thema sind Micro Frontends. Sie bringen eine Idee ins Frontend, die man im Backend in Form von Microservices und Service-orientierten Architekturen schon lange hatte. Erfahrungsgemäß bekommt man große Monolithen nach einiger Zeit schlecht gewartet. Man will diese also in viele kleine Anwendungen aufsplitten, die dann getrennt deployt und entwickelt werden können. So können vielleicht auch Frameworks getrennt upgegradet oder komplett unterschiedliche Frameworks eingesetzt werden. Das ist eigentlich der Gedanke hinter dem Thema Micro Frontends.
Mirko Hillert: Das klingt interessant. Aber warum macht man das?
Hans-Christian Otto: Es gibt viele verschiedene Gründe, da sind die Menschen auch unterschiedlicher Meinung. Für mich ist einer der größten Punkte die Skalierung von Teams. Ähnlich sehe ich das auch bei Microservices im Backend. Wenn man eine gewisse Teamgröße erreicht hat und erkennt, dass man vielleicht mit zwanzig Leuten noch an einer Codebase arbeiten kann, mit fünfzig Leuten dann aber nicht mehr so gut, dann kann man anfangen das Ganze zu zerlegen, sodass man nur noch zehn oder fünf Entwickler pro Team hat. Die können dann auch unterschiedliche Frameworks einsetzen. Das ist wiederum interessant, weil dann nicht mehr nur Angular-Entwickler im Unternehmen sein müssen. Es können beispielsweise auch React-Experten hinzugezogen werden, sodass ein Teil der Applikationen als React-Anwendung gemacht wird. Das ist für mich das beste Argument. Es gibt auch Leute, für die es vielleicht wichtig ist, auf die modernen Technologien zu setzen und bei Neuentwicklungen mal schnell etwas mit Vue.js machen zu können, was ja einer der Shootingstars am JavaScript-Himmel ist. Ähnlich ist es im Backend bei Microservices gewesen. Ich glaube, das ist der Grund, warum man sich mit dem Thema auseinandersetzt.
Mirko Hillert: Wie setzt man Micro Frontends um?
Hans-Christian Otto: Da gibt es viele verschiedene Varianten. Man kann das mit einer Variante machen, die quasi vom Anfang an im Web da war. Heutzutage entwickeln viele Leute gerne Single Page Applications. Man kann aber diesen sogenannten Hyperlink verwenden. Dann ist da die Landingpage mit dem Log-in-Formular, die eine Single Page Application darstellt – das ist ein kleines Micro Frontend. Wenn man sich einloggt, wird man woanders hin redirected. Wenn man dann auf die Profilansicht des eigenen Profils geht und die Einstellungen wechseln möchte, wird man wieder auf eine komplett andere Seite weitergeleitet, die dann hoffentlich ein wenig ähnlich aussieht aber komplett unabhängig voneinander entwickelt werden kann. Das ist ein möglicher Ansatz. Ein anderer ist, innerhalb eines DOMs mehrere Applikationen zu laden, wie etwa eine React-Anwendung mehrfach innerhalb einer Seite zu bootstrappen. Somit haben wir beispielsweise eine Anwendung, die die Navigation macht, eine die den Content anzeigt und wieder eine andere erzeugt rechts eine Statusleiste, auf der Änderungen herunterlaufen. Es können drei verschiedene Applikationen auf einer Seite sein. Diese können alle mit React entwickelt sein, man kann aber auch React und Angular auf einer Seite vermischen.
Das geht normalerweise relativ gut, kann aber auch zu Problemen führen. Ich habe mal ein Projekt erlebt, bei dem viele kleine Micro Frontends auf einer Seite liefen. Die wurden alle mit der gleichen React-Version geschrieben, haben aber teilweise die gleichen Bibliotheken genutzt. Leider hatten wir Bibliotheken dazwischen, die Global State gebraucht haben. Daraufhin hat das eine Micro Frontend diesen Global State verändert und das zweite hat dadurch seinen Eintrag aus dem Global State verloren. Auf einmal hat die Applikation nicht mehr funktioniert. In unserem Fall verschwanden dadurch Teile des Styles – das war ziemlich ärgerlich.
Deshalb gibt es noch einen weiteren Ansatz. Ein Wort, das viele Entwickler erschrecken lässt: iframes. Wir haben eine sogenannte Shell.Application, die drumherum liegt und darin haben wir verschiedene kleine iframes, die die verschiedenen Micro Frontends beinhalten und laden. Das führt dazu, dass man die Frontends tatsächlich sehr stark voneinander losgelöst und getrennt hat. Diese Applikationen voneinander zu isolieren kann ein Ziel bei Micro Frontends sein. Das bedeutet auch, wenn die eine Applikation mit einer Exception das React komplett abrauchen lässt und es gar nicht mehr reagiert, betrifft es nur diesen iframe. Das zieht natürlich auch ein paar Nachteile mit sich. Wir laden React nämlich sechsmal und haben dementsprechend sechsmal React auf der Seite, wenn wir da fünf verschiedene Micro Frontends und die Shell.Application haben. Aber diesen Ansatz finde ich sehr spannend.
Ich glaube zudem, dass iframes ihre schlimmsten Zeiten hinter sich haben. Ich persönlich habe damit noch keine Architektur gemacht. Aber das wäre etwas, das auszuprobieren sicherlich interessant wäre, und das ist einer der möglichen Ansätze dazu.
Mirko Hillert: Wenn wir mit Micro Frontends viele kleine Anwendungen haben, wie erreichen wir, dass der Benutzer trotzdem eine konsistente Nutzeroberfläche sieht?
Hans-Christian Otto: Indem wir uns ganz viel Mühe geben. Das ist tatsächlich ein Problem, das ich auch selbst erlebt habe. In einer Anwendung mit acht, neun Micro Frontends hatten wir plötzlich acht, neun verschiedene Implementierungen eines modalen Dialogfelds, das über der Seite auftaucht. Dann war auf der Hälfte der Anwendung der Hintergrund abgedunkelt und auf der anderen aufgehellt. Das war also alles andere als konsistent. Manchmal hatte man dann runde Ecken um den modalen Dialog, manchmal waren sie eckig, manchmal hatten sie einen Schatten und manchmal nicht. Das ist natürlich ein Problem.
Einen Ansatz, den ich dabei für sehr sinnvoll erachte, der aber auch abhängig davon ist, wie man ihn umsetzt, ist eine Komponentenbibliothek. Man hat also ein npm-Paket, bei Blendle zum Beispiel nennen sich diese Components „Lego“ – das sind also die Bausteine, aus denen sie die Anwendung zusammensetzen – das finde ich einen sehr schönen Namen. Dann kann man dafür sorgen, dass es wieder einigermaßen konsistent wird. Das funktioniert natürlich nur dann richtig gut, wenn alle das gleiche Framework verwenden. Wenn also alle Micro Frontends auf React aufsetzen, kann man sehr gut React-Komponenten entwickeln, die zwischen den Micro Frontends gesharet werden können. Ein typisches Problem an der Stelle ist, dass diese Komponentenbibliotheken übersehen werden. Das kennen glaube ich die meisten Entwickler: Man hat irgendwo eine Komponentenbibliothek, aber niemand weiß, welche Komponenten eigentlich existieren. Niemand sieht die. Da gibt es mittlerweile glücklicherweise mittlerweile Tools wie Storybook für React, Angular, Vue und für Polymer ist es glaube ich gerade in der Entwicklung. Mit denen kann man diese Komponentenbibliothek leicht sichtbar und ausprobierbar machen. Man kann sie so gestalten, dass auch Designer über Änderungen diskutieren können. Das ist ein recht guter Ansatz. Aber es klappt wie gesagt nur, wenn wir alle die gleiche Technologie einsetzen. Ansonsten muss man sicherlich darüber nachdenken, dass das auf CSS-Ebene passieren kann und man sich dasselbe Stylesheet teilt. Das ist etwas, wozu auch Jens Grochtdreis sehr wertvollen Input geliefert hat. Ich persönlich bin kein CSS-Experte, weshalb ich versuche, diesen Weg nicht zu gehen; das funktioniert aber natürlich auch.
Du hast eingangs gesagt, dass es gestern einen Speaker Panel gab. Wir haben das gestern tatsächlich noch mal ein bisschen anders gemacht. Wir haben versucht, auch die Teilnehmer der JavaScript Days zu involvieren. So saßen auch einige Teilnehmer mit vorne und haben mitdiskutiert. Auch aus dem Publikum gab es eine Menge Input zu dem Thema. Ein Teilnehmer sagte: „Eigentlich ist das mit der Konsistenz häufig gar nicht das Problem des Kunden“, das fand ich sehr schlau. Wenn ich auf einem Onlineshop bin und alle Buttons grün sind und nur der Knopf zum Kaufen bzw. Ausloggen ist plötzlich blau, fällt mir das als Benutzer oft gar nicht auf. Wenn man aber die CI der Firma von grün auf rot umstellt, dann sollte das natürlich überall geschehen. Aber für solche Kleinigkeiten ist die Konsistenz keine Top-Priorität. Man sollte einheitlich aussehen, aber ob der Button nun grün oder blau ist, ist in den wenigsten Fällen wichtig. Man kann es zudem nach ein, zwei Wochen noch korrigieren.
Mirko Hillert: Die Diskussionsrunde hatte „Fluch oder Segen“ als Untertitel. Gibt es noch ein weiteres Fazit, das du aus der Diskussion mitgenommen hast?
Hans-Christian Otto: Ich glaube, das größte Fazit war, wie so oft in der Softwareentwicklung: „Es kommt drauf an“. Wir haben gestern sicherlich alle festgestellt, dass Micro Frontends viele Probleme lösen können, aber – wie so vieles in der Softwareentwicklung – auch einen Berg an Kosten und Problemen mitbringen, um die muss sich dann wieder kümmern muss. Wir hatten gerade schon die Konsistenz – im Zweifelsfall lädt man auch siebzehnmal React runter, wenn man siebzehn Micro Frontends hat. Wenn man das nicht tut, dann werden es andere kleine Bibliotheken sein. Oder man hat siebzehn verschiedene DOMs auf einer Seite, wenn man siebzehn iframes einbindet. Das sind natürlich alles Probleme.
Auf der anderen Seite ermöglicht das natürlich auch eine Entwicklung in einer anderen Skalierung. Man kann mit deutlich mehr Entwicklern deutlich effizienter vorwärtskommen. Unser Fazit ist, dass man sich klarmachen sollte, ob man in der Größenordnung von Facebook, Spotify, Google oder GitHub ist, wo man dieses Problem auch braucht. Oder ist man vielleicht in der Situation, dass man ein sehr altes Framework hat und auf eine neue Version migrieren möchte, aber keinen Cut machen möchte. Denn wenn man zwei Jahre lang eine neue Version entwickelt, ist die dann nur in zwei Jahren leider auch veraltet, weil sie ja vor zwei Jahren angefangen wurde. Stattdessen kann man auch einfach einzelne Teile der Anwendung nehmen, mit neuen Komponenten entwickeln und diese in die alte einbinden. Oder andersherum.
Das ist sicherlich auch ein Einsatzgebiet von Micro Frontends, wo es Sinn macht. Ich glaube, der wichtigste Punkt ist, dass es kein Allheilmittel ist und wir nicht immer alle Micro Frontends machen sollten. Es kann Gründe geben, warum man das machen sollte, die können einem auch sehr helfen. Aber pauschal, nur um Micro Frontends zu machen – das ergibt keinen Sinn.
Mirko Hillert: Christian, ich danke dir für das Interview.
Interviewt von: Mirko Hillert
Mirko Hillert verantwortet seit 2007 als Leiter der Entwickler Akademie den Trainingsbereich bei Software & Support Media. Er studierte Betriebswirtschaft an der Westsächsischen Hochschule Zwickau und der Universidad Valencia sowie Marketing an der Westfälischen Wilhelms-Universität Münster. Als ehemaliger Dozent und Ausbilder für Managementprozesse treibt er seit vielen Jahren die fundierte Aus- und Weiterbildung von Entwicklern und Softwarearchitekten im IT-Markt voran, unter anderem mit innovativen Eventformaten und hochwertigen Trainingsinhalten.
