Nadmiarowy kod wysłany w dół z Micro-frontendami

Rozumiem Micro-frontends, że kluczowym problemem, który rozwiązują, jest pomaganie przedsiębiorstwom w tworzeniu wielu, możliwych różnych zespołów, pracy nad poszczególnymi komponentami / małymi aplikacjami, które będą używane do tworzenia dużej aplikacji internetowej.

Kluczowym problemem do rozwiązania jest tutaj zdolność wielu zespołów do samodzielnej pracy i wciąż w stanie zbudować duży kompozyt. Problem NIE dotyczy posiadania pakietu lean release dla użytkownika końcowego . Czy to zrozumienie jest prawidłowe?

Czy to prawda, że ​​jeśli mamy wiele małych aplikacji używanych do tworzenia dużej aplikacji internetowej, możemy potencjalnie mieć wiele małych aplikacji wysyłających tę samą bibliotekę JavaScript ( taką jak Lodash ) do przeglądarek użytkowników końcowych w ramach ich poszczególne pakiety dostawców prowadzące do wysłania pewnej ilości zduplikowanego / nadmiarowego kodu do użytkownika?

Czy nie jest to problem, który powinniśmy martwić podczas projektowania aplikacji front-end?

Masz całkowitą rację, że wiąże się to z kompromisem: handlujesz niektórymi aspektami doświadczenia użytkownika, aby uzyskać lepszą jakość pracy programisty (co z kolei może poprawić wrażenia użytkownika na różne sposoby). Czy to jest tego warte? To zależy.

Np. Myślę, że Spotify wykorzystuje to podejście do podzielenia interfejsu użytkownika na izolowane komponenty ( źródło ). Każdy widżet żyje w ramce iframe, a zatem może mieć własny zestaw bibliotek itp. Mają one wyjątkowy charakter organizacyjny, polegający na tym, że praca jest wykonywana przez niezależne oddziały (zespół interdyscyplinarny). Utrudnia to uzgodnienie standardów obowiązujących w całej firmie, a później ich zmianę. Dla nich mikro-frontendy pomagają zachować pewną elastyczność. Ale bez tego podejścia być może ich aplikacja komputerowa nie byłaby świnią pamięci.

Buforowanie HTTP niewiele pomoże: każda mikro-frontend może używać różnych wersji frameworka. Dodatkowo koszt duplikacji to nie tylko transfer danych, ale także koszty (ponownego) kompilowania bibliotek i przechowywania zduplikowanych struktur danych po stronie klienta.

Osobiście uważam, że takie mikro-nakładki mogą być prawidłową architekturą, ale prawdopodobnie nie są zalecane, chyba że

• jesteś bardzo dużą organizacją z wysoce autonomicznymi zespołami, które wszystkie pracują nad interfejsem użytkownika i muszą robić bardzo częste wydania (np. codziennie) i
• Twój budżet wydajności UX ma miejsce na to powielanie lub twój produkt jest tak dobry, że UX nie ma znaczenia. Należy pamiętać, że wydajność należy przetestować na urządzeniach klasy niskiej, a nie na komputerze deweloperskim.

Jeśli Twoja organizacja nie jest duża lub jeśli twoje zespoły są nieco bardziej wyspecjalizowane, może być łatwiej dla wszystkich zaangażowanych (kierownictwo, programistów i ostatecznie użytkowników) mieć wspólny proces budowania i wdrażania, który pozwala uniknąć niepotrzebnego powielania. Np. Jeśli masz tylko 4 zespoły pracujące nad interfejsem użytkownika, prawdopodobnie mogą ze sobą rozmawiać w celu uzgodnienia wspólnego zestawu bibliotek i sposobu zintegrowania ich pracy w spójną architekturę.

Mikro-nakładki wydają się być jedną z tych rzeczy, które są naprawdę fajne, ale których nie potrzebujesz, dopóki nie zaczniesz działać na dużą skalę.