Module Federation: Dokončni vodnik po deljenju modulov med izvajanjem v mikro-frontendih

V nenehno razvijajočem se svetu spletnega razvoja smo priča pomembnemu arhitekturnemu premiku. Potovali smo od monolitnih arhitektur do mikroservisov v zaledju, v iskanju razširljivosti in avtonomije ekip. Zdaj ista revolucija preoblikuje tudi frontend. Prišla je doba mikro-frontendov, v njenem osrčju pa leži močna tehnologija, ki vse to omogoča v praksi: Module Federation.

Osrednji izziv mikro-frontendov je bil vedno preprost za opredelitev, a težaven za rešitev: kako zgraditi enotno, kohezivno uporabniško izkušnjo iz več neodvisno objavljenih aplikacij, ne da bi ustvarili počasno, preobloženo in neobvladljivo zmedo? Kako deliti skupno kodo, kot so knjižnice komponent ali ogrodja, kot je React, ne da bi povzročili nočne more z različicami ali prisilili v usklajene objave?

To je problem, ki ga Module Federation elegantno rešuje. Predstavljen v Webpack 5, to ni zgolj še ena funkcija; je paradigmatski premik v našem razmišljanju o gradnji in uvajanju spletnih aplikacij. Ta celovit vodnik bo raziskal, kaj, zakaj in kako deluje Module Federation, s poudarkom na njeni najbolj transformativni zmožnosti: deljenju modulov med izvajanjem.

Kratek povzetek: Kaj so mikro-frontendi?

Preden se poglobimo v mehaniko Module Federation, uskladimo, kaj mislimo z mikro-frontendi. Predstavljajte si veliko spletno trgovino. V monolitnem svetu je celoten frontend – iskanje izdelkov, podrobnosti o izdelkih, nakupovalna košarica in zaključek nakupa – ena sama, velika aplikacija. Sprememba gumba za zaključek nakupa bi lahko zahtevala testiranje in ponovno objavo celotne aplikacije.

Arhitektura mikro-frontendov razbije ta monolit po poslovnih domenah. Morda imate:

• Ekipo za iskanje, ki je odgovorna za iskalno vrstico in stran z rezultati.
• Ekipo za izdelke, ki je odgovorna za podrobnosti o izdelkih in priporočila.
• Ekipo za zaključek nakupa, ki je odgovorna za nakupovalno košarico in postopek plačila.

Vsaka ekipa lahko neodvisno gradi, testira in objavlja svoj del aplikacije. To prinaša več ključnih prednosti:

• Avtonomne ekipe: Ekipe lahko delajo in objavljajo po lastnem urniku, kar pospeši razvoj.
• Neodvisne objave: Hrošč v mehanizmu za priporočila ne blokira kritične posodobitve plačilnega procesa.
• Tehnološka prilagodljivost: Ekipa za iskanje bi lahko uporabljala Vue.js, medtem ko ekipa za izdelke uporablja React, kar ekipam omogoča izbiro najboljšega orodja za svojo specifično domeno (čeprav to zahteva skrbno upravljanje).

Vendar pa ta pristop prinaša svoje izzive, predvsem glede deljenja in doslednosti, kar nas pripelje do starih načinov dela.

Stari načini deljenja kode (in zakaj so nezadostni)

V preteklosti so ekipe poskušale z več metodami deljenja kode med različnimi frontend aplikacijami, vsaka s pomembnimi pomanjkljivostmi v kontekstu mikro-frontendov.

NPM paketi

Najpogostejši pristop je objava deljenih komponent ali pripomočkov kot različica NPM paketa. Klasičen primer je knjižnica deljenih komponent.

• Problem: To je odvisnost v času gradnje (build-time). Če ekipa A posodobi deljeno komponento `Button` v `my-ui-library` z različice 1.1 na 1.2, ekipi B in C te posodobitve ne bosta prejeli, dokler ročno ne posodobita svojega `package.json`, zaženeta `npm install` in ponovno objavita celoten mikro-frontend. To ustvarja tesno povezovanje in izniči namen neodvisnih objav. Prav tako vodi do nalaganja več različic iste komponente v brskalniku, kar napihne končni paket.

Monorepos z deljenimi delovnimi prostori

Monorepos (z uporabo orodij, kot so Lerna ali Yarn/NPM workspaces) ohranjajo vse mikro-frontende v enem samem repozitoriju. To poenostavlja upravljanje deljenih paketov.

• Problem: Čeprav monorepos pomagajo pri razvijalski izkušnji, ne rešujejo osrednjega problema med izvajanjem. Še vedno se zanašate na odvisnosti v času gradnje. Sprememba v deljeni knjižnici še vedno zahteva, da se vse aplikacije, ki jo uporabljajo, ponovno zgradijo in objavijo, da se sprememba odrazi.

Zunanje skripte preko oznak `