Smashing Podcast Episode 6 z Lucą Mezzalirą: Czym są mikrofrontendy?

Kończymy ten rok kolejnym podcastem Smashing! Tym razem porozmawiamy o mikro-nakładkach. Co to jest mikro-frontend? Czym różni się od podejścia, które możemy obecnie przyjąć? Dowiedzmy się od pioniera mikro-frontendu, Luki Mezzaliry.

Pokaż notatki

Cotygodniowa aktualizacja

• „Dodawanie funkcji dynamicznych i asynchronicznych do witryn JAMstack”, Jason Lengstorf
• „Narzędzia danych ilościowych dla projektantów UX”, Adonis Raduca
• „Tworzenie umiejętności głosowych dla Asystenta Google i Amazon Alexa”, Tris Tolliday
• „Poza sprintem 0: alternatywa dla integrujących się zespołów”, Shamsi Brinn
• „Pomaganie przeglądarkom w optymalizacji dzięki właściwości zawierającej CSS” — Rachel Andrew

Mikrofronty

• Strona internetowa Luki Mezzaliry
• Luca na Twitterze
• „Mikro-frontendy, przyszłość architektury frontendowej” na Medium
• Więcej informacji, które Luca pisze o mikro-nakładkach, można znaleźć na jego koncie Medium
• Książka Luki „Architektury reaktywne front-end”

Transkrypcja

Drew McLellan: Jest ekspertem ds. programistów Google w zakresie technologii internetowych i menedżerem londyńskiej społeczności JavaScript. Z ponad 15-letnim doświadczeniem, obecnie pracuje jako wiceprezes ds. architektury, projektując sportową platformę wideo DAZN, która dostarcza treści sportowe na żądanie milionom użytkowników oglądających na żywo. Jest autorem książki Front-End Reactive Architectures dla Apress, a także recenzentem technicznym dla Apress, Packt Publishing, Pragmatic Bookshelf i O'Reilly, a także doświadczonym mówcą publicznym na konferencjach technicznych na całym świecie. Jest Włochem, nosi ładną brodę i wyraźnie ma głęboką wiedzę na temat platformy internetowej. Ale czy wiesz, że kiedyś przemierzył Amerykę Południową na strusiu? Moi miażdżący przyjaciele, proszę powitajcie Lucę Mezzalirę. Cześć, Luko. Jak się masz?

Luca Mezzalira: Rozwalam .

Drew: Chciałbym dzisiaj porozmawiać z Tobą na temat mikro-frontendów. Teraz jest to koncepcja, która jest dla mnie zupełnie nowa, z pewnością z samej nazwy, i spodziewam się, że jest również nowa dla wielu naszych słuchaczy. Zanim przejdziemy do samych mikro-frontendów, myślę, że powinniśmy zrozumieć problem, który chcesz za ich pomocą rozwiązać. Więc może mógłbyś powiedzieć nam trochę o tym, jak postrzegasz aplikacje w bardziej tradycyjny sposób i jakie problemy napotykają te rzeczy, na które być może mikro-frontendy mogą być rozwiązaniem?

Luca: Dobra, moim zdaniem to dobry punkt wyjścia. Dlatego zazwyczaj, gdy wdrażasz lub projektujesz nowy projekt od podstaw i chcesz pracować z aplikacjami typu front-end, masz do dyspozycji kilka architektur, które możesz wykorzystać. Możesz użyć aplikacji jednostronicowej, aplikacji renderującej po stronie serwera lub aplikacji wielostronicowej złożonej z prostych stron HTML. Oczywiście są to bardzo ważne opcje i myślę, że są bardzo używane przez wielu, wielu programistów. Prawdziwym problemem, który próbujemy tutaj rozwiązać, jest to, jak możesz skalować te koncepcje z rozproszonymi zespołami do setek programistów pracujących na tej samej bazie kodu, ponieważ rzeczywistość jest taka, gdy pracujesz w szczególności na tych platformach, gdy myślisz o Na przykład platforma SaaS, musisz mieć wielu programistów i wiele zespołów, które pracują nad tym samym projektem. I oczywiście sposób, w jaki na przykład dokonujesz akwizycji lub retencji, jest zupełnie inny od sposobu, w jaki eksponujesz katalog lub jak pokazujesz konkretną część platformy.

Luca: Z mojego doświadczenia wynika, że ​​dużo pracuję z aplikacjami jednostronicowymi. Pracuję z aplikacją do renderowania po stronie serwera, ale w pewnym momencie w DAZN zostałbym poproszony o zastanowienie się nad sposobem skalowania naszego zespołu technicznego. I muszę wymyślić… jeśli dla backendu mamy jakieś rozwiązanie, które w tym przypadku są mikroserwisami, to możemy niezależnie skalować nasze API i brać pod uwagę skalę i wolumen dla określonej przepustowości na konkretnym API. Na froncie, naprawdę, jest to naprawdę trudniejsze, ponieważ jeśli się nad tym zastanowisz, nie masz problemów technicznych do rozwiązania, gdy musisz skalować, na przykład, jeśli używasz aplikacji jednostronicowej. Prawdopodobnie w przypadku renderowania po stronie serwera masz trochę, ale na przykład w aplikacji jednostronicowej jest ona dystrybuowana z natury, ponieważ jest po stronie klienta, inna po stronie klienta.

Luca: Więc jedyne, co ładują, to tylko niektóre statyczne pliki, takie jak CSS, HTML i JavaScript, które są obsługiwane przez CDN, aw takim przypadku można odpowiednio skalować, nie jest to duże wyzwanie. Ale prawdziwym wyzwaniem jest skalowanie zespołów pracujących na tej samej platformie, ponieważ czasami wyzwania, przed którymi stoi jeden zespół, mogą być zupełnie inne niż wyzwania, przed którymi stoi inny zespół, a zwykle starasz się znaleźć wiele kompromisów między rzeczami. Bo jeśli myślisz, spróbujmy pomyśleć o normalnym przypadku użycia. Więc zwykle, kiedy zaczynasz platformę, zaczynasz od małej. Więc próbujesz stworzyć tę szybką aplikację jednostronicową, a także masz swój monolit, więc po prostu konfigurujesz wszystko w swoim CICD tylko raz dla frontendu i backendu, a następnie zaczynasz iterować swoją logikę. Ale rzeczywistość jest taka, że ​​kiedy odniesiesz sukces, musisz rozwinąć tę część i nie zawsze utrzymuje się tę samą architekturę, która może, powiedzmy, przynieść korzyści dla Twojej firmy, ponieważ może uda Ci się znaleźć jakieś wąskie gardła.

Luca: A teraz wróćmy do jednostronicowej części aplikacji. Więc jeśli chcemy skalować jednostronicową część aplikacji, wyzwanie nie jest techniczne, ale jeśli chcesz, to z ludźmi. Jak więc możemy skalować zespoły pracujące na tej samej aplikacji. Kilka lat temu zacząłem więc przyglądać się możliwej architekturze i zasadom, które pozwoliłyby mi skalować zarówno frontend, jak i backend. Pracuję więc nad zasadami backendu, aby można było znaleźć mikroserwisy. Zacząłem przyglądać się różnym rozwiązaniom i wyszli z mikro-nakładkami, których na początku nawet tak nie nazywaliśmy, bo oczywiście przez lata nie było takiej nazwy dla tej konkretnej architektury .

Luca: Ale rzeczywistość przyjmuje monolit, a więc jednostronicową aplikację i pokrojenie jej w sposób, który pozwoli nam skupić się na malutkim problemie. A więc mniejszy problem niż cała aplikacja i próba rozwiązania go w najlepszy możliwy sposób. Z technicznego punktu widzenia. Oczywiście prowadzi to do posiadania niezależnych części aplikacji frontendowej, które można wdrożyć w środowisku produkcyjnym bez wpływu na wszystkie inne. Tak więc wyzwaniem dla mikro-frontendu jest próba wymyślenia sposobu, aby wziąć pojedynczą stronę aplikacji lub aplikację renderowaną po stronie serwera i stworzyć artefakt z nich, powiedzmy, jak najbliżej domeny biznesowej i można go wdrożyć niezależnie .

Drew: Mam na myśli, że wspomniałeś o mikroserwisach na zapleczu. Więc koncepcyjnie jest to podobne rozwiązanie problemu. Mikrousługi służą z tyłu, ale zostały przeniesione na front. Czy to zgrubna ekwiwalentność, czy jest to bardziej z tym związane?

Luca: Tak. Nie, jest to sposób na rozwiązanie tego samego problemu, który próbuje rozwiązać w tym czasie mikrousługi na zapleczu, ale na froncie. Zwykle, kiedy zaczynałem tę podróż na początku, wiesz, zaczynasz o tym myśleć i zaczynasz oceniać różne podejścia. W ciągu ostatnich kilku miesięcy wymyśliłem to, co oni nazywają, ramy decyzyjne mikro-frontendu, które w zasadzie składają się z czterech kroków, których używają, aby, powiedzmy, określić podejście do mikro-frontendu, ponieważ jeśli do tej pory, my zwykle wybieramy jeden framework, który zaprojektował dla nas architekturę, a my wdrażamy na jego architekturę. Jeśli myślisz o Angularze lub myślisz o React lub Redux. Masz wszystkie potrzebne elementy, ale nie podejmujesz decyzji architektonicznych. Podjąłbyś decyzje projektowe lub sposób implementacji na tej konkretnej architekturze.

Luca: Więc w Micro-frontendzie trzeba zacząć krok wstecz. Musimy więc pomyśleć o tym, jak najpierw chcemy pokroić naszą aplikację. Zwykle są na to dwie opcje. Możesz ciąć poziomo, dzięki czemu możesz mieć wiele mikro-frontendów w tym samym widoku lub możesz ciąć w pionie. Dlatego zawsze ładujesz jedną Micro-frontend na raz. A ta decyzja jest dość kluczowa, ponieważ spowoduje kaskadę pewnych innych opcji, które masz w oparciu o początkową decyzję. Tak więc po pierwsze, jak już powiedziałem, decydujesz, jak chcesz podzielić swoją aplikację. Drugi to sposób, w jaki chcesz skomponować swoją aplikację. Chcesz więc mieć na przykład powłokę aplikacji, która ładuje jeden lub wiele mikro-frontendów w tym samym widoku. Chcesz mieć, nie wiem, serwer aplikacyjny, który będzie komponował różne fragmenty twoich aplikacji, czyli inny Micro-frontend, a następnie serwowałby końcowy widok twojemu użytkownikowi. Lub chcesz użyć dołączonej krawędzi, jest to standard, który znajduje się w sieciach CDN, aby skomponować stronę i tam ją wyświetlić.

Luca: To są trzy opcje, które masz. A potem oprócz komponowania, musisz pomyśleć, jak chcesz trasować. Więc nie wiem, w jaki sposób trasujesz z /login lub /signin do części katalogu lub konkretnego obiektu szczegółu. Również tutaj masz trzy opcje. Możesz to zrobić na serwerze aplikacji, możesz to zrobić na poziomie CDN z Lambda Edge lub dowolnymi innymi pracownikami sieciowymi w CloudFlare lub czymkolwiek innym. Lub możesz zrobić stronę klienta. Więc masz logikę w powłoce aplikacji, którą mówisz, w porządku, teraz dla tego konkretnego adresu URL musisz załadować inny widok lub inną mikro-frontend. A ostatni fragment to sposób komunikowania się z Micro-frontendem.

Luca: Zwykle więc, jeśli masz wiele mikro-frontendów na tej samej stronie, zarządzanie tą komunikacją jest bardziej skomplikowane, ponieważ musisz zachować niezależność różnych mikro-frontendów. Oznacza to, że nie możesz mieć żadnego odniesienia do struktury strony. Dlatego zwykle możesz użyć takich rzeczy, jak zdarzenia niestandardowe lub miernik zdarzeń, który jest wstrzykiwany do każdej pojedynczej mikro-frontendu. A potem Micro-frontend komunikują się ze sobą. Oczywiście w drugim przypadku, gdy masz, powiedzmy, podział wertykalny, Twój mikro-frontend jest o wiele łatwiejszy, ponieważ w pionie zasadniczo reprezentacja pionowego mikro-frontendu jest pojedynczą aplikacją lub pojedynczą stroną. W takim przypadku łatwiej jest powiedzieć, że tworzenie i udostępnianie ma wspólny stan w całym Micro-frontendzie.

Luca: Zatem jeśli myślisz o posiadaniu wielu mikro-frontendów razem, powinieneś unikać stanów, które są wspólne dla mikro-frontendu, ponieważ w przeciwnym razie łączysz różne rzeczy. Zamiast całej koncepcji tutaj jest oddzielenie i niezależne wdrożenie. I dlatego powiedzmy, że wyzwania związane z podziałem poziomym, który jest pierwszą decyzją, którą powinieneś podjąć, lub podziałem pionowym, są zupełnie inne i musimy być bardzo świadomi, który z nich pasuje do naszego przypadku użycia.

Drew: Więc zamiast konkretnego rozwiązania technicznego, mikronakładki są bardzo podobne do wzorca projektowego, który można zaimplementować w dowolnej technologii, która jest odpowiednia dla konkretnego problemu, który próbujesz rozwiązać?

Luca: Tak, bardziej niż technologia, chciałbym zobaczyć, że wybieramy odpowiednią architekturę do właściwej pracy. Dla przykładu, mówiłem... istnieje sławny framework, całkiem nowy dla Micro-frontendu, nazywa się Luigi framework, który został wydany przez SAP open source. To, co robią, to tworzenie ramek iframe, w których umieszczają swój mikro-frontend. Więc teraz, jeśli myślisz o tym, powiedzmy, używaniu iframe w dzisiejszych czasach, jesteś na publicznej stronie internetowej, która może jako SEO lub inne funkcje, które są obowiązkowe, może to być problematyczne.

Luca: Ale w przypadku SAP, jeśli się nad tym zastanowić, mają oni aplikację korporacyjną, w której mogą kontrolować przeglądarkę, której używa użytkownik, mogą kontrolować środowisko, nie muszą być dostępne na wielu lub inna wersja przeglądarki. Więc dla nich to pozwala im mieć pewne obszary aplikacji, które są stałe i mają pewne obszary, które zmieniają się niezależnie bez żadnego problemu. Ale oczywiście rozwiązanie iframe nie zadziałałoby w innej sytuacji. Aby podać inny przykład, Spotify, na początku używamy ramek iframe. W rzeczywistości publikacja biurkowa nadal składa się z wielu ramek iframe, a każda pojedyncza ramka jest maleńką aplikacją, która, nie wiem, jest tylko odtwarzaczem muzyki lub tylko ich rekomendacją, cokolwiek to jest. Próbują zastosować to samo podejście w sieci, ale odrzucili to w tym roku, aby wrócić do aplikacji jednostronicowej.

Luca: A to oznacza, że ​​wyjaśniają, dlaczego na blogu technicznym mówili, że oczywiście, jeśli zastosujesz to do milionów użytkowników, którzy używają ramek iframe, które muszą ładować za każdym razem ten sam plik dostawcy. A potem masz dużo zduplikowanych zależności i czas interakcji z twoją stroną byłby dłuższy. Tak więc w rzeczywistości to podejście może pasować do niektórych przypadków użycia, ale nie powinno pasować do wszystkich z nich. Dlatego mówię, tak jak opisałem wcześniej, jeśli masz ramy decyzyjne, które pomagają ci to rozwiązać i możesz zacząć mówić, okej, podzieliłem aplikację w ten sposób, dlatego mam te opcje, które są dostępne kiedy chcę komponować, kiedy chcę trasować, kiedy chcę się komunikować, to powinno cię prowadzić, aby podjąć właściwą decyzję we właściwym czasie.

Luca: Więc oczywiście poza tymi czterema decyzjami jest wiele innych. Na przykład sposób, w jaki tworzysz spójność w systemie projektowania, który masz we wszystkich mikro-frontendach. Albo nie wiem, jak zarządzasz zależnościami i unikasz kolizji zależności wewnątrz Micro-frontendu, ale rzeczywistość jest taka, że ​​te cztery decyzje, o których wspomniałem wcześniej, pozwolą ci następnie podjąć wszystkie inne w szybki sposób bez konieczności posiadania problem przemyślenia, co jest najlepszym rozwiązaniem, bo już postawiłeś kamień węgielny, czyli cztery filary, które pozwolą Ci podjąć wszystkie inne decyzje… nie mówię w łatwy sposób, ale w szybszy sposób niż recenzja lub spektrum możliwości.

Drew: Wspomniałeś wcześniej, w jaki sposób Micro-frontend może pomóc w takiej strukturze zespołów w Twojej organizacji, w której wiele osób pracuje nad tą samą aplikacją. Jakie są wtedy konsekwencje i czy ma to jakiekolwiek znaczenie, jeśli wasze zespoły są rozproszone lub współlokalizowane, czy też stoją tam jakieś wyzwania?

Luca: Tak. Mogę więc opowiedzieć, jaka jest historia DAZN. To jest firma, w której pracuję. Obecnie w DAZN mieliśmy fajne wyzwanie. Tak więc obecnie mamy ponad 300 osób, które pracują z przodu i z tyłu naszej platformy. To platforma OTT, która transmituje na żywo wydarzenia sportowe na całym świecie. A ciekawe jest to, czy wszystkie mikroserwisy, które wiemy, jak zarządzać mniej więcej, i mamy rozproszone zespoły. Mamy więc cztery centra deweloperskie. Chcielibyśmy umieścić zespoły w każdym centrum deweloperskim na froncie, a wypróbowaliśmy to podejście i działa to całkiem dobrze. Dzięki Micro-frontendowi byliśmy w stanie zapewnić różne domeny biznesowe w różnych lokalizacjach i umożliwić komunikację krzyżową między zespołami w określonej domenie biznesowej, ponieważ jest to najgorszy scenariusz, jeśli musisz porozmawiać z innym zespołem w tej samej domenie biznesowej , po prostu dotrzesz na odległość spaceru od swojego biurka. Jeśli zamiast tego musisz omówić konkretną rzecz w zespole dystrybucyjnym, to może z kimś w Londynie zamiast w Amsterdamie lub zamiast firmy w Polsce, po prostu organizujesz telefon.

Luca: Ale takie rodzaje komunikacji są rzadsze niż te, które mają miejsce między zespołami w tej samej lokalizacji. I dlatego zaczęliśmy nad tym pracować. Tak więc pierwszą rzeczą, którą zrobili, było sprawdzenie, w jaki sposób nasi użytkownicy wchodzą w interakcję z naszą witryną internetową, jak skonstruowana jest firma. A kiedy zidentyfikujemy cztery kluczowe obszary, nad którymi pracujemy, a które są obecnie pozyskiwaniem i utrzymaniem, powiedzmy przeniesienie ich podstawowej aplikacji na wiele telewizorów i urządzeń mobilnych oraz posiadanie podstawowej domeny, którą dla nas jest odtwarzacz wideo i faza odkrywania nasze treści. I na koniec wszystkie elementy zaplecza biurowego. Udało mi się zidentyfikować te cztery obszary, a my te cztery obszary, które przypisaliśmy do każdego pojedynczego centrum deweloperskiego.

Luca: Oczywiście istnieją pewne punkty kontaktu między tymi obszarami, ale są też sposoby, aby, powiedzmy, złagodzić i przeprowadzić wstępne warsztaty z różnymi zespołami, które znajdują się w różnych lokalizacjach, a następnie pracować na przykład nad tym samym kontraktem API lub ten sam cel z posiadaniem kilku punktów kontrolnych podczas rozwoju. Ale miłą rzeczą w podejściu, która pozwoliła podejść z Micro-frontendem, jest fakt, że w końcu dogłębnie rozumiemy, jak działał nasz system. Siadamy i analizujemy naszą strukturę i zmieniamy nie tylko sposób, w jaki wpłynęło to na nas, ale także sposób działania firmy. I to było trochę inne podejście od tego, co widzieli do tej pory. Ale to udowadnia, że ​​działa to całkiem dobrze w przypadku, gdy każdy zespół może wchodzić w interakcje z zespołem z tej samej lokalizacji w tej samej domenie.

Luca: Więc jeśli mówisz o projektowaniu opartym na domenie, mówią dokładnie w tym samym języku. A to dlatego, że jeśli potrzebują interakcji z innymi zespołami, mogą dosłownie podzielić się warsztatem lub polecieć do innego centrum deweloperskiego i to nie jest problem. Ale w ten sposób, powiedzmy, zwiększamy przepustowość i zmniejszamy narzuty na komunikację oraz zakres zależności, które miały miejsce w innej sytuacji, nad którą pracowali.

Drew: A czy wszystkie te zespoły muszą używać standardowego frameworka JavaScript? Czy wszystkie muszą kodować w tych samych rzeczach, wszystkie muszą być typu React lub Angular, czy też umożliwić interoperacyjność między nimi, czy też ludzie mogą używać różnych rzeczy dla różnych mikro-frontendów?

Luca: Tak. Tak więc w DAZN zdecydowaliśmy się podzielić wertykalnie nasz mikro-frontend i to była decyzja, która pozwoliła nam mieć swobodę wyboru technologii, której potrzebujemy dla każdego pojedynczego mikro-frontendu. Biorąc pod uwagę, że za każdym razem ładujemy jeden Micro-frontend na raz, a to oznacza, że ​​na przykład sposób, w jaki mamy stronę docelową, różni się od drogi logowania / rejestracji. Możemy więc aktualizować… obecnie używamy głównie Reacta. Ale jeśli na przykład pamiętam, kiedy React 16 był wydaniem, które mogliśmy wydać w wersji produkcyjnej React 16, również jeśli nie był w wersji stabilnej tylko dla strony docelowej i zobaczę, czy działał bez wpływu na wszystkie inne zespoły.

Luca: A potem we własnym tempie, we własnym tempie, aktualizowali swoje własne rzeczy. Dzięki temu możemy również, powiedzmy, wypróbować nowe technologie lub nowe założenia, które mamy na istniejącej aplikacji z określoną liczbą użytkowników. Ponieważ wdrażamy również wersje kandydujące do frontendu. Wdrażamy, powiedzmy, kilka praktyk, które pozwalają nam po prostu wypróbować określone czasy w produkcji i zobaczyć, jak działają.

Luca: Piękno tych podejść, które możemy niezależnie zdecydować o posiadaniu odpowiedniego narzędzia do właściwej pracy, jest czymś więcej niż posiadaniem wspólnego mianownika w całym stosie. Bo jak możesz sobie wyobrazić, kiedy zaczynałeś pracę nad projektem, decyzja, którą podjąłeś przez pierwsze kilka lat, jest prawdopodobnie inna od decyzji, którą podjąłeś na trajektorii, w której firma się rozwija, biznes ewoluuje i stają się bardziej dojrzałe a wyzwanie jest zupełnie inne. Więc nie byłoby wystarczająco elastyczne ani wystarczająco zwinne, jeśli pomyślisz o tym, że trzymamy się tej samej decyzji, którą podjęliśmy dwa lata temu. W szczególności instytucja taka jak DAZN, w której w ciągu trzech lat przechodzimy od zera do 3000 pracowników. Jak możesz sobie wyobrazić, był to ogromny wzrost i był to ogromny wzrost zarówno dla firmy, jak i dla bazy użytkowników.

Drew: Czy istnieje ustalony sposób, w jaki różne mikro-frontendy mogą udostępniać dane i komunikować się ze sobą, na przykład, aby utrzymać się nawzajem w tym samym widoku, czy jest na to sposób?

Luca: Tak, jest. Zależy to od ram decyzyjnych, którą ścieżką zamierzasz obrać. Ponieważ jeśli zamierzasz wziąć pionowy kawałek, to stało się to bardzo łatwe. Więc to, co mamy, aby komunikować się przez Micro-frontend, to powłoka aplikacji, która ładuje się w Micro-frontendzie wewnątrz siebie. A to, co robi, to przechowywanie wszystkiego, co ma być, powiedzmy, udostępniane w różnych mikro-frontendach lub w pamięci sieciowej, w sesji, w pamięci lokalnej lub w pamięci. A następnie na podstawie tych informacji ładowany jest mikro-frontend, który może pobrać z powłoki aplikacji te informacje, a następnie wykorzystać je, zmienić lub zmienić. To zależy całkowicie od tego, jak podzielisz aplikację, ale w tym przypadku, aby podać przykład, jeśli myślisz, kiedy jesteś uwierzytelnionymi użytkownikami i musisz przejść do strony logowania, kiedy jesteś i interfejsy API są przez nas wykorzystywane i udostępniają token JWT, Micro-frontend przekazuje je do powłoki aplikacji, a powłoka aplikacji, po uruchomieniu których zapisaliśmy ich pamięć internetową.

Luca: Następnie powłoka aplikacji ładuje nowy uwierzytelniony obszar dla tej konkretnej aplikacji i tych uwierzytelnionych obszarów, pobiera token JWT z powłoki aplikacji i wykonuje albo odświeżający token dostępu, albo weryfikuje niektóre dane, zaczynając od wewnątrz token JWT. Wykorzystuje więc w zasadzie informacje, które zostały wyprodukowane przez inny Micro-frontend na ich własnym kole.

Drew: Brzmi to bardzo ciekawie i dostrzegam wiele zalet pracy w ten sposób, ale z pewnością nie może się to obejść bez wyzwań. Czy są jakieś konkretne rzeczy, z którymi trudniej sobie poradzić przy projektowaniu rzeczy w ten sposób?

Luca: Myślę, że przede wszystkim głównym wyzwaniem, które widzę, jest zmiana sposobu myślenia. Ponieważ wcześniej byliśmy przyzwyczajeni do, powiedzmy, liderów technicznych lub głównych programistów, którzy decydowali o wszystkim wokół całej aplikacji, podejmując wszystkie decyzje. Teraz w końcu przechodzimy od tej scentralizowanej jednostki do zdecentralizowanej jednostki, która jest lokalna dla każdego stanu. Jak możesz sobie wyobrazić, niesie to ze sobą pewne wyzwania, ponieważ jeśli wcześniej mieliśmy kogoś, kto śledzi ścieżkę, teraz mamy, powiedzmy, wiele osób na górze określających właściwą ścieżkę w swojej domenie, a to ogromna zmiana nastawienia.

Luca: Z drugiej strony myślę, że złożoność polega na akceptacji, że czasami robienie złej abstrakcji może być, powiedzmy, droższe niż powielanie kodu. Wiem, że jest coś, co było dla mnie bardzo trudne w zarządzaniu programistami, ponieważ myślą: „OK, teraz mogę ponownie użyć tego obiektu lub tej konkretnej biblioteki setki razy w projekcie”, ale rzeczywistość jest zupełnie inna. Widziałem bibliotekę komponentów, która była abstrakcyjna i spędzali dużo czasu na tworzeniu tego jako najlepszego kodu w historii lub najlepszego w idealnym kształcie. Ale rzeczywistość została wykorzystana tylko dwa razy. Więc wysiłek włożony w zrobienie tego nie był dokładnie taki. Widziałem po drugiej stronie biblioteki, które zaczynały od kilku przypadków użycia dla określonego komponentu. A potem te przypadki użycia zmieniły się w 10, a kod stał się nie do utrzymania.

Luca: Zatem próba dodania nowej funkcji w tym samym komponencie może być bardziej ryzykowna niż korzyścią. Myślę więc, że inną rzeczą, którą musimy zrozumieć w przypadku Micro-frontendu, jest to, jak bardzo chcemy go udostępniać, a ile powielać. I nie ma nic złego w powielaniu. W naszym przypadku na przykład mamy zduplikowaną stopkę i nagłówek, a zrobiliśmy to głównie dlatego, że zmieniliśmy nagłówek trzy razy w ciągu czterech lat. Więc jak możesz sobie wyobrazić, że centralizujemy je, jesteśmy przypisani do zespołu i tworzymy zewnętrzną zależność dla wszystkich zespołów, wszystkich setek programistów, których mamy, jest bardziej powiedzmy kwestią niż korzyścią dla firmy, ponieważ nie dodajemy ogromnej wartości.

Luca: W tym samym czasie refaktoryzujemy nasze biblioteki współdzielone, które byłyby biblioteką płatności, ponieważ oczywiście płatność ma za tym pewną logikę i jeśli chcemy zmienić raz, nie chcemy stosować tego dwa razy w wielu częściach kod. Chcemy mieć tylko jedną bibliotekę, która jest źródłem prawdy, ale dla nagłówka i stopki, także jeśli jest rozbieżność lub dla piksela lub jest funkcja, która zostanie wdrożona tydzień później, nie zaszkodzi to wniosek.

Drew: Czy są więc jakieś charakterystyczne oznaki, których ludzie powinni szukać, oceniając aplikację i myśląc: „O tak, to byłby dobry kandydat do przejścia na architekturę typu micro-frontend?”

Luca: Tak, więc moja sugestia byłaby przede wszystkim taka, że ​​nie zaczynałbym projektu od podstaw z Micro-frontendem, chyba że dokładnie wiemy, jak powinien być zbudowany. I zwykle jest bardzo mało prawdopodobne, że masz te informacje, ponieważ szczególnie jeśli masz nową platformę lub nowy projekt i po raz pierwszy nad tym pracujesz, znalezienie tych informacji może być nietrywialne. Zwykle sugeruję rozpoczęcie od istniejącej architektury, która byłaby aplikacją jednostronicową, a następnie jej rozwijanie. W szczególności na przykład stwierdziłem, że używanie mikro-frontendu do starszych aplikacji lub gdy chcemy wymienić konkretną część aplikacji lub gdy mamy projekt, który chcemy rozwijać i skalować dla wielu zespołów, to są trzy przypadki użycia że czuję się bardzo silny, może pasować do architektury Micro-frontend. Oczywiście nie oznacza to, że od teraz wszystko powinno być robione na mikro-frontend, ponieważ mikro-frontend wcale nie jest srebrną kulą.

Luca: Tym, czym są, jest dodatkowa architektura, którą możemy wykorzystać w świecie front-endu. I do tej pory mieliśmy pewną ilość architektur, teraz mamy dodatkową. Ale to dużo wyzwań, ponieważ oczywiście musisz, jeśli przed renderowaniem po stronie serwera lub aplikacją jednostronicową, istnieją wyraźne wzorce, które zostały zbadane, a następnie zaimplementowane przez kilka frameworków i tak dalej. Obecnie z mikro-frontendem jest to jeden ze sposobów na robienie rzeczy. Ale dodanie ram decyzyjnych prawdopodobnie powinno pozwolić ludziom na podejmowanie właściwych decyzji dla ich przypadków użycia. Ponieważ często pojawia się wiele nieporozumień na temat tego, czym jest Micro-frontend i jak należy go używać. I wiele osób myśli, że może, powiedzmy, są złe z powodu, nie wiem, posiadania zbyt wielu bibliotek w jednym widoku lub innych rzeczy.

Luca: Rzeczywistość jest taka, że ​​musisz dogłębnie zrozumieć koncepcję, zrozumieć, jak ją wdrożyć, a potem możesz zacząć nad tym pracować. W pełni zgadzam się, że są wyzwania techniczne i jest wiele decyzji, które musisz podjąć i nie możesz tak po prostu zacząć od razu z edytorem przed sobą, pisząc kod i myśląc, ok, teraz tworzę mikro-frontend architektura. Ponieważ musisz zrozumieć koncepcję, zrozumieć kontekst i tworzyć, a także zarządzać tym, ponieważ złożoność nie polega tylko na napisaniu kodu, ale także na zrozumieniu, jak wszystkie elementy pasują do siebie w części CICD, części dotyczącej SEO i tak dalej.

Luca: Tak więc Micro-frontend zapewnia, powiedzmy, pewien poziom elastyczności i wymaga wiele wysiłku, aby zdefiniować prawo do zarządzania. Bo gdy będziesz mieć odpowiednie zarządzanie, wszystko będzie gładko. Często i niestety powiedziałbym zbyt często, widziałem firmy, w których nie spędzają wystarczająco dużo czasu po stronie zarządzania, na przykład rozumiejąc CICD, ponieważ uważają, że to nie jest ważne. Ale zamiast tego w przypadku mikro-frontendu, podobnie jak w przypadku mikroserwisów, posiadanie prawa do automatyzacji pozwoli Ci przyspieszyć rozwój. Jeśli nie poświęcisz wystarczająco dużo czasu na automatyzację, ryzykujesz większe obciążenie niż korzyści.

Drew: Wydaje mi się, że w świecie tworzenia stron internetowych jest wiele rzeczy, w których ludziom grozi zagłębienie się w rozwiązania techniczne, zanim naprawdę zrozumieją problem. Wygląda na to, że w przypadku mikro-frontendu trzeba zobaczyć problem, a następnie wdrożyć rozwiązanie, aby wiedzieć, jaki problem rozwiązujesz. Myślę, że sama natura mikro-frontendu sprawia, że ​​bardzo łatwo jest rozpocząć integrację z istniejącą aplikacją, wykryć mały problem i zamienić go z mikro-frontendem w celu rozwiązania tego problemu. Czy to rozsądna sugestia?

Luca: Tak, tak bym powiedział. W tym przypadku jedyną rzeczą, którą sugerowałbym, jeśli zaczniemy w ten sposób, jest spojrzenie bardziej na cięcie pionowe nad cięciem poziomym, ponieważ w przeciwnym razie trzeba rozwiązać tak wiele problemów, załóżmy na przykład, że używasz Angulara i chcesz przejść na nową wersję Angulara. Jeśli potrzebujesz mieć dwie wersje Angular mieszkające razem bez użycia I-frame, może to być skomplikowane lub nawet niemożliwe. Więc jeśli zaczynasz, to nie od… jeśli sprawdzasz wyzwanie, nie z technicznego punktu widzenia, ale z biznesowego punktu widzenia. Może na przykład możesz wziąć, nie wiem, część dotyczącą logowania, w której chcesz napisać inną wersję lub tę samą wersję, ale bardziej zaktualizowaną wersję frameworka i to może być dobry sposób. A potem kierujesz się ścieżką. To może być dobry sposób na powolne, ale stabilne zastąpienie określonej aplikacji.

Luca: To, co zrobiliśmy w naszym przypadku, to w zasadzie zastosowanie wzorca dusiciela, który jest dobrze znanym wzorcem dla mikroserwisów, ale na interfejsie. Tak więc na podstawie adresu URL oraz przeglądarki i kraju użytkownika. Tak powoli, ale systematycznie, w zasadzie zabijaliśmy monolit, który w tym przypadku był aplikacją jednostronicową, częściej wypuszczając naszą nową aplikację i sprawdzając zachowania użytkowników, jeśli poprawiało to wrażenia, powodowało to problemy w naszym systemie albo nie. A to pozwoliło nam zapewnić natychmiastową wartość biznesowi, ale jednocześnie pozwoliło nam przetestować nasze założenia i sprawdzić, czy idziemy w dobrym kierunku, czy nie.

Drew: Brzmi to jak bardzo atrakcyjne rozwiązanie niektórych problemów, z którymi z pewnością boryka się wiele osób. Jeśli ja, jako programista, chciałbym zacząć więcej dociekać o mikro-frontendzie, gdzie byłbym dobry początek?

Luca: Tak, więc obecnie spędzam dużo wolnego czasu, próbując opowiadać się za tą architekturą, ponieważ myślę, że jest wiele nieporozumień. Na moim koncie Medium. Napisałem kilka artykułów, które są tam również dostępne. Nagrano wiele filmów z konferencji, które bez problemu można znaleźć na YouTube. A druga rzecz, którą sugeruję, jeśli szukasz przykładowego kodu na niektórych frameworkach, to ten, od którego sugerowałbym na początek, to pojedynczy SPA, głównie dlatego, że ma podejście pionowego slicingu, łatwiej go pobrać i możesz zacząć rozumieć korzyści płynące z tej architektury. Jest też wiele innych, które są dostępne. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.