Mikrofrontendy jsou zajímavá adaptace konceptu microservices pro potřeby frontendového vývoje. Podívejte se, co to v praxi obnáší a proč jsme se v Seznam.cz rozhodli vyvinout náš vlastní microfrontend framework, Merkur.
Jestli jste někdy řešili nasazování aplikace, asi víte, že všechno odladit může být celkem zdlouhavá záležitost. Dokážete si představit, že na to máte jen týden? Že je to nemožné? Není! Jde to a ani to nemusí být příliš složité.
Reportáž z virtuální konference FOSDEM. Minule jsem popsali Go room, dnes se věnujeme monitoringu a observability.
Jak bylo na virtuální konferenci FOSDEM.
Definice
Tá definice o mikrofrontende mi znie nie len prapodivná, ale není to vlastne definícia pre komponentový prístup, aký je bežný vo front-ende už snáď 10 rokov? A že „Při bližším pohledu se ale ukázalo, že většina frameworků nesplňuje naše potřeby.“ tak to ani Svelte? Lebo ten by som povedal že to splňuje viac než dobre.
V jednoduchosti je krasa
Ja robim mikfronden apky nejako takto https://gitlab.com/peryl/happ
SSR?
Ano, to je pravda. Urcite je to jeden z dalsich pristupu pro SPA. Dival, jsem se na poslany link, ale SSR demo jsem tam nenasel. Asi se jenom spatne divam.
Není framework jako framework
Pokud by ty jednotlivé widgety byly ve stejné technologii, vytvářené pokud možno stejným týmem pak ano, dal by se na to použít běžný komponentový přístup.
Microfrontend pattern se používá hlavně v situacích, kde je potřeba poskládat web z částí tvořených v různých technologiích (třeba kvůli přechodu na novou technologii, nebo protože ty části tvoří různé týmy používající různé technologie). A dále je častý požadavek, aby ty komponenty byly server-side-rendered kvůli SEO.
Ten „framework“ se pak nestará o samotné vykreslení komponent, ale o posbírání server-side vykreslených widgetů z jejich API a poskládání do funkční stránky, tedy o úplně jinou úlohu, než kterou řeší Svelte / React / Angular / Vue / ..
mikrofrontend na Seznamu
Ano, je to znát, Seznam se stává pomalejším, uživatelsky méně přívětivým, náročným na prostředky. To je daň za použití takových fíčur.
To nesúhlasím
@L. tak u Svelte to nesúhlasím, Svelte práveže má všetko čo ste popísali, vie to SSR, môžeš v tom použiť z ľubovolných technológií/frameworkov vytvorené komponenty, môžeš to spojiť a vykresliť.
Takže Svelte umí out-of-the-box při SSR přes nějaké API (jaké?) načíst kus stránky vyrenderované jiným frameworkem a umístit ho do renderované stránky včetně korektního napojení skriptů a CSS?
Proče ne typescript
Zajímavý projekt.
Nechápu použití čistého js. Kdyby to byl nějaký hobby projekt, tak proč ne, ale u projektu, který bude mít pravděpodobně značný scope nepoužít typescript – to mi hlava nebere.
Máte k tomu nějaký důvod?
áno
@L. áno, vie to.
Ono to skoro vypadá jako boj mezi Svelte a Merkur, ale to bych řekl, je špatné porovnání. Spíše je to tak, že je možné použít Svelte s Merkurem stejně jako ostatní předpřipravené knihovny. Integrující aplikaci (napsané v PHP, Node, Python, atd.) je jedno jestli je widget psaný v Preactu, Svelte, v čistém JS nebo dokonce na klientu bez JS.
Na HP Seznamu Merkur použitý není. Na jakém zařízení a prohlížeči zaznamenáváte problém?
Merkur je 100 let za opicema!
Jdete pozde chlapci a devcata. Renderovani pres API je dead, ted frci websockets! 8-) https://alistapart.com/article/the-future-of-web-software-is-html-over-websockets
@tonda Myslim, si ze zalezi pripad od pripadu, ale treba React predstavil Server Components, kde pouziva API. Urcite neni problem Merkur upravit na WebSocket pokud by bylo potreba. Podle clanku mate v Merkuru taky vsechno na jednom miste. Je mozne se pripojit primo do DB nebo konzumovat nejake API. Zalezi na potrebach widgetu ;-)
@martin Planujem do budoucna zlepsit podporu pro TypeScript, ale zasadne by to tedka nemelo branit pokud by nekdo chtel psat widget v TypeScriptu. Nemeli jsme zasadni duvod ho pouzit. Proc si myslite, ze je to tak dulezite?