Host app - rozkmina

[mzastue]

Zastanawiam się nad scenariuszem gdzie mamy hosta zbudowanego na Vite + React + Federation, ale remote'ty używają różnych frameworków. Powinno to być bezproblowe prawda? Tylko trzeba pamiętać, że host nie może udostępniać niczego co jest związane z danym frameworkiem, ponieważ remote'a nie zinterpretuje tego.

[marcin-kopanski]

@mzastue more zacznijmy od ogółu do szczegółu, jeśli chodzi o host to może określmy najpierw co w ramach hosta chcemy skonfigurować -> jakie pakiety, czy bawimy się w linty, prettiery itd czy może podejdziemy do tego na czysto -> sam inicjalny Vite template z plugiem Module Federation?

uważam ze stworzymy kilka różnych hostów by dać podstawę do różnych rozwiązań jakie będziemy chceli zaspokoić bo nic złego nie jest w tym by host udostępniał np cala bibliotekę ui (primeflex, materiał) a micro były budowane w ramach tego samego systemu. oczywiście to jeden ze scenariuszy

inny zdecydowanie powinien uwzględnić niezależność ui pomiędzy dwoma micro i hostem

ale może właśnie zaczniemy od podstawy, zdefiniowania samej konfiguracji samego projektu na którego bazie będziemy budowali hosty i micro. takiego projektu który może być developowany przez samodzielny zespol a który odpowiednio skonfigurowany będzie mógł działać jako host, micro czy tez może jedno i drugie jednocześnie (?)

[marcin-kopanski]

z grubsza proponuje by za taka podstawę posłużył template który stworzyłem jako podstawę do: https://github.com/marcin-kopanski/react-vite-boiler

[mzastue]

jeśli chodzi o host to może określmy najpierw co w ramach hosta chcemy skonfigurować -> jakie pakiety, czy bawimy się w linty, prettiery itd czy może podejdziemy do tego na czysto -> sam inicjalny Vite template z plugiem Module Federation?

Tak, na pewno jak najbardziej czysty, więc klasyczna konfiguracja + federatoion. Jednak na pewno też prettier, lint, itd. Jeśli chcemy propagować linta na inne projekty, że miały te same ustawienia to jakieś inne podejście trzeba by przyjąć np. common package instalowany do package.json. Raczej?

uważam ze stworzymy kilka różnych hostów by dać podstawę do różnych rozwiązań jakie będziemy chceli zaspokoić bo nic złego nie jest w tym by host udostępniał np cala bibliotekę ui (primeflex, materiał) a micro były budowane w ramach tego samego systemu. oczywiście to jeden ze scenariuszy [...] inny zdecydowanie powinien uwzględnić niezależność ui pomiędzy dwoma micro i hostem

Jak najbardziej tak. Też myślałem o tym, żeby mieć kilka wersji hosta przystosowaną do różnych podejść.

ale może właśnie zaczniemy od podstawy, zdefiniowania samej konfiguracji samego projektu na którego bazie będziemy budowali hosty i micro. takiego projektu który może być developowany przez samodzielny zespol a który odpowiednio skonfigurowany będzie mógł działać jako host, micro czy tez może jedno i drugie jednocześnie (?)

Myślę, żeby mieć jasny podział: host to host, remote to remote. Repozytorium na hosta, na podstawie któego można sobie sklonować i zacząć używać projekt + remote tak samo.

Ja sobie zacząłem robić też drugi boilerplate, na razie pewnie nie taki rozbudowany jak Twój, ale mam to w jednym repo tylko po to, żeby było w jednym miejscu. Nie dodaje tam na razie żadnego turbopacka, czy innego monorepo-toola.

[mzastue]

z grubsza proponuje by za taka podstawę posłużył template który stworzyłem jako podstawę do: https://github.com/marcin-kopanski/react-vite-boiler

Później pewnie bym popracował nad strukturą samego jeszcze, żeby jakąś fajną praktyke dobrać do tego. Clean architecture, można też zastosować Screaming architecture żeby mieć poukładane pionowo.

[mzastue]

Dorzuciłem od siebie na razie coś - zupełna podstawa. Robię tez sobie na boku, żeby porównać podejścia i jakoś zmergować w jedno potem ;)

https://github.com/Frontend-Next/vite-microfrontends-mat/tree/main

[mzastue]

Dorzuciłem też routing - chyba jest taki sam jak u Ciebie, ale inaczej to rozłożyłem strukturę plików https://github.com/Frontend-Next/vite-microfrontends-mat/pull/2

Jest jedna różnica - jeśli remote jest używany jako microfront to routing ma ustawiony basename a jeśli traktowany jest jak serwowany oddzielnie to basename jest /