Tartalomjegyzék[Elrejt][Előadás]
A mikroszolgáltatások ötlete az utóbbi időben nagy figyelmet kapott, és sok cég használja fel a nagy, monolitikus háttérrendszerek megszüntetésére.
Ugyanazon az úton haladni a frontenddel még mindig kihívást jelent sok vállalkozás számára, még akkor is, ha a webalkalmazások szerveroldali felépítésének ez az elosztott módja a kutatás és a végrehajtás szempontjából többé-kevésbé megbízható.
Szoros függősége miatt az ügyféloldali monolit jellemzően megnehezíti az új funkciók integrálását, az új technológiák átvételét és az egyes komponensek méretezését.
Ezek és más kihívások késztették a frontend fejlesztőket a mikroszolgáltatások használatának vizsgálatára.
Ennek eredményeként egy vadonatúj architekturális stratégiát fejlesztettek ki, amelyet micro frontend néven ismerünk a webhelyek és webalapú alkalmazások front-end rétegének létrehozására.
A kifejezést először 2016-ban használták, és azóta nagy figyelmet kapott egy jó ügy érdekében.
Ez a cikk általános képet ad arról, hogy mik azok a mikrofelületek, és milyen problémákkal foglalkoznak. működik, valamint előnyei és hátrányai is.
Bevezetés a mikro front-end architektúrába
A front-end fejlesztés kortárs módszere, az úgynevezett mikro-frontend architektúra megosztja a webalkalmazás apró, független részekre.
A végfelhasználó számára ezek az alkatrészek egy egységnek tűnnek, még akkor is, ha egymástól függetlenül készültek, majd összerakták őket.
Azzal a különbséggel, hogy a mikro frontendek az online megoldások kliens oldalára vonatkoznak, nem szerveroldalra, a mögöttük rejlő logika megegyezik a mikroszolgáltatásokéval.
A kifinomult webalapú termékek készítése a mikrofrontend megközelítés alkalmazásakor a legértelmesebb.
A hagyományosabb előtér-monolittal szemben a mikro frontendek sok csapat számára lehetővé teszik, hogy külön-külön együttműködjenek a különböző szoftverprojektekben.
A programozók gyorsabban, nagyobb skálázhatósággal és karbantarthatósággal hozhatnak létre webalkalmazásokat ezzel az építészeti kialakítással.
Egyszerűen fogalmazva, minden mikro-frontend csak egy kódrészlet a weboldal egy különálló összetevőjéhez.
Ezeket a funkciókat külön csapatok irányítják, amelyek mindegyike egy adott iparágra vagy célkitűzésre specializálódott.
Monolit vs Microservices vs Micro frontend architektúra
Gondolj a költözésre. Egyszerűbb lesz, ha mindent több kis, szakszerűen felcímkézett dobozba rendez, és mindegyiket külön-külön áthelyezi, vagy a teljes személyzetet egy hatalmas dobozba csomagolja és új helyre szállítja?
A kézenfekvő megoldás megvan.
Ez az analógia összehasonlítja a két különböző webalkalmazás-architektúrát, a monolitokat és a mikroszolgáltatásokat (más néven mikro-frontendeket).
Monolit építészet
Talán felidézheti a „régi szép időket”, amikor egy teljes alkalmazás egyetlen, összefüggő egységként jött létre. Az ilyen módszert monolitnak nevezik, ami egy régi kifejezés a nagy kőtömbökre.
Ennek van értelme.
A monolitikus rendszereknek egymásra épülő elemei vannak. Ezért, ha módosítani szeretne valamit, vagy új szolgáltatást szeretne hozzáadni, lehetséges, hogy az egész rendszer meghibásodhat.
Annak ellenére, hogy elavult, időnként még mindig létezik. Igen, tisztában vagyunk a jelenlegi kifejezésével.
A kódbázis fogalmi felosztása két különböző komponensre – frontend (kliens oldali) és backend (szerveroldali) – elkerülhetetlenné vált az új technológiák kifejlesztésével és a szoftvertermékek bonyolultabbá válásával.
A legnépszerűbb működési módszer ma az aggodalmak szétválasztása a prezentációs réteg, amellyel a végfelhasználó interakcióba lép, és minden, ami a háttérben történik.
Két szoftvermérnöki csapatra van szükség, a front-end csapat a vizuális komponenseket, a back-end csapat pedig a webszolgáltatásokat, üzleti logikát, adatelérést, integrációkat stb.
Ez a stratégia azonban e szétválasztás ellenére továbbra is monolitikus marad.
A fő változás az, hogy egy hatalmas alkalmazás helyett két méretes kódblokk áll rendelkezésünkre – a frontend és a háttérrendszer. A monolitikus építészetnek nem kell szörnyűnek lennie; van néhány előnyük, többek között
- Egyszerű és gyors fejlesztés apró alkalmazásokhoz egyetlen forráskódbázissal és nagyon egyszerű kialakítással;
- A tesztelés és a hibakeresés nagyon egyszerű, mivel az összes kód egy helyen található, így a csapat könnyebben követheti a kérés folyamatát és azonosíthatja a hibákat;
- Az alkalmazások fejlesztésének korai szakaszában a költségek olcsóbbak, mivel sem infrastrukturális költségek, sem fejlesztési költségek nem merülnek fel, amíg új funkciókat nem adnak hozzá.
Ennek a stratégiának a hátrányai tükröződnek
- Korlátozott telepítési rugalmasság – a csapatoknak várniuk kell, ha csak néhányan dolgoznak a projekten, és minden alkalommal új telepítésre van szükség, amikor frissíti a kódot;
- Az új technológiák átvétele kihívást jelent, mivel ehhez a projekt jelentős részét, ha nem az egészet át kell írni.
- A fejlesztők számának növekedésével egy kódrendszer szorosan összekapcsolódik, bonyolulttá, nehezen kezelhetővé és érthetővé válik.
- Szervezeti problémák – minden csapattagnak a könyvtárak ugyanazt a verzióját kell használnia, és jelentenie kell a változásokat, ha sok csapat dolgozik egy monolitikus projekten.
- A skálázhatósággal kapcsolatos aggályok – mivel a projekt komponensei össze vannak kötve, ezek külön-külön történő skálázása nehézségeket okoz, ami jelentős leállást és magasabb kiadásokat eredményez.
- A projekt összetett logikája nehezen érthető lehet az új csapattagok számára, különösen akkor, ha az eredetileg a projekten dolgozó mérnökök már nincsenek foglalkoztatva.
A mikroszolgáltatások és közeli hozzátartozóik, valamint a mikro frontendek fejlesztése a monolitikus rendszerekkel kapcsolatos elsődleges problémákat oldotta meg.
Mikroszolgáltatások architektúrája
A mikroszolgáltatásként ismert architekturális módszer lehetővé teszi számos, lazán kapcsolódó és egymástól függetlenül telepíthető kisebb komponens vagy szolgáltatás létrehozását, amelyek egy alkalmazási háttérrendszert alkotnak.
Minden szolgáltatásnak saját kódbázisa, CI/CD-folyamatai, DevOps-eljárásai és futtatási folyamatai vannak.
A fenti képen láthatja, hogy a monolitikus háttércsapat külön csapatokra oszlik.
Mindegyik külön-külön az alkalmazás más-más aspektusára összpontosít (például termékszolgáltatásra, keresési szolgáltatásra és fizetési szolgáltatásra).
A szolgáltatások közötti kommunikáció API-ként ismert protokollokon keresztül történik, például a könnyű REST API protokollon, amely szinkron kérés-válasz mintákat használ.
Egy másik lehetőség az aszinkron kommunikáció használata olyan szoftverek segítségével, mint a Kafka, amely közzétételi/előfizetési kommunikációs struktúrákat és eseményeket kínál.
A mikroszolgáltatások a frontend (BFF) szolgáltatás háttérrendszerén vagy a hálózaton keresztüli API-átjárón keresztül integrálódnak az előtérbe. A BFF testreszabott API-t kínál minden ügyfél számára, míg az API-átjárók egyetlen hozzáférési pontot biztosítanak a mikroszolgáltatások gyűjteményéhez.
De még az autonóm háttér-összetevők és az általuk nyújtott előnyök mellett is az előtér továbbra is monolit.
Ezért itt hasznosak a mikro frontendek.
Mikro frontend architektúra
A mikroszolgáltatásokhoz hasonlóan, ahol a lazán összekapcsolt komponenseket több csapat kezeli, a mikro frontend architektúra a böngészőre alkalmazza a koncepciót.
Ezek a webalkalmazások felhasználói felületei ezt a struktúrát követik, amely némileg autonóm komponensekből áll.
A csapatok az ügyfelek igényei vagy használati esetei alapján jönnek létre, nem pedig speciális szakértelem vagy technológia alapján.
Következésképpen a csapatok részt vesznek a mikroszolgáltatásokban és a mikro frontend projektekben.
- függőlegesen szeletelve – mivel frontend fejlesztők, adatszakértők, backend mérnökök, minőségbiztosítási mérnökök stb. is dolgoznak ugyanazon a projekten, ők hozzák létre a szolgáltatásaikat a felhasználói felület adatbázisokhoz; és
- keresztfunkcionális – minden csapattag hozzájárul szakértelmével a csoporthoz.
A csapatok kiválaszthatják az adott üzletáguknak leginkább megfelelő technológiai halmazt is.
Egy csapat a React segítségével programozhatja a töredékét. Egy másik csapat új Angular verziót készít. A Vue.js egy ilyen példa.
A mikro-frontendeket a kapcsolódó mikroszolgáltatásokkal együtt használják a fejlesztőcsapatok által a monolitokkal kapcsolatos problémák megoldására. A stratégia a következő előnyöket kínálja.
- Technológiai szabadság: A Frontend mérnökei alternatív JavaScript-keretrendszereket, futásidejű környezeteket és teljes technológiai halmazokat választhatnak a vállalat igényeitől függően. Az elavult architektúrán felül egy új keretrendszer is alkalmazható.
- Nagyobb fokú rugalmasság lehetséges, mivel minden mikro-frontend önálló, és külön fejleszthető, tesztelhető, telepíthető és frissíthető. Ennek eredményeként, ha az egyik csapat egy funkción dolgozik, és hibajavítást nyújtott be, és egy másik csapatnak hozzá kell adnia saját funkcióját, akkor nem kell megvárnia, amíg az első csapat befejezi a feladatát.
- Autonóm csapatok és rendszerek: Minden termékcsapat, következésképpen minden egyes funkció, úgy működhet, hogy nem függ másoktól, ami lehetővé teszi, hogy továbbra is működjön akkor is, ha a közeli összetevők nem állnak rendelkezésre.
- Több, kisebb kódbázis: Mindegyik mikro-frontendnek saját, jobban kezelhető, kisebb kódbázisa lesz. Kevesebb ember fog egy adott felhasználói felület-összetevőre összpontosítani, egyszerűsíteni a kódok áttekintését és javítani az általános szervezést.
- Egyszerű alkalmazásméretezés: A mikro-frontendek másik előnye, hogy minden funkciót külön-külön méretezhetnek. Ellentétben a monolitokkal, ahol a teljes programot minden új funkció hozzáadásakor méretezni kell, ez az egész folyamatot hatékonyabbá teszi mind idő, mind pénz tekintetében.
Hogyan működik a mikro frontend?
Amint azt korábban kifejtettük, a csapatok vertikálisan szerveződnek a mikro frontend architektúrán belül, ami azt jelenti, hogy a tartomány tudása vagy célja elválasztja őket, és az elejétől a végéig felelősek egy adott termékért.
Lehet benne egy vagy két háttér-mikroszolgáltatás, valamint egy kis előtér. Vizsgáljuk meg részletesebben ennek a vizuális elemnek a jellemzőit, interakcióit más UI-komponensekkel és a kezdőlapba való beépülését.
Mikro frontend lehet
- egy teljes oldal (pl. egy termékrészletet tartalmazó oldal), ill
- az oldal azon részei, amelyeket más csapatok is használhatnak, például a fejléceket, lábléceket és keresősávokat.
Egy nagy webhelyet több oldaltípusra is feloszthat, és mindegyik típust egy adott munkatársnak adhatja, hogy dolgozzon rajta.
Azonban számos komponens gyakran előfordul számos oldalon, például fejlécek, láblécek, javaslatblokkok stb. Egy javaslatblokk például szerepelhet a kezdőlapon, a termék részleteit tartalmazó oldalon vagy akár a fizetési oldalon.
Lényegében a csapatok olyan darabokat hozhatnak létre, amelyeket más csapatok használhatnak az oldalaikon.
A mikro frontendek azonban külön-külön is telepíthetők különböző projektekként, szemben az újrafelhasználható komponensekkel.
Mindez fantasztikusan hangzik, de az egységes felület létrehozásához az oldalakat és a töredékeket valahogy kombinálni kell.
Ehhez frontend integrációra van szükség, amely különféle stratégiákkal valósítható meg, beleértve az útválasztást, a kompozíciót és a kommunikációt (lásd a fenti ábrát).
útvonalválasztás
Ha az egyik csapat által felügyelt oldalról származó szolgáltatás szükséges egy másik csapat tulajdonában lévő oldal eléréséhez, az útválasztás hasznos az oldalszintű integrációhoz.
Minden mikrofelületet egyoldalas alkalmazásként kezelünk. Egyszerű HTML hivatkozások használhatók az útválasztáshoz.
A felhasználó rákényszerítheti a böngészőt, hogy töltse le a céljelölést egy szerverről, és a hiperhivatkozásokra kattintva cserélje le az aktuális oldalt egy újra.
Az alkalmazáshéj a HTML, CSS és JavaScript minimális eleme, amely a felhasználói felületet vezérli. Még ha a szervertől kért tartalomadatok még várakoznak is, a felhasználó azonnal statikusan megjelenített oldalt kap. A központi alkalmazáshéj szülőalkalmazásként szolgál a különböző csapatok által létrehozott egyoldalas alkalmazások számára.
Függetlenül attól, hogy milyen könyvtárat vagy keretrendszert használunk, a meta-keretrendszerek lehetővé teszik a különböző oldalak egyetlen egybeolvadását.
Összetétel
A kompozíció az a folyamat, amikor a darabokat úgy rendezzük el, hogy az oldal megfelelő helyére illeszkedjenek. A legtöbb esetben az oldalt telepítő csapat nem kéri le azonnal a töredék tartalmát.
Ehelyett egy helyőrzőt vagy jelölőt helyez el oda, ahol a töredéknek lennie kell a jelölésben.
Egy másik összeállítási eljárással a végső összeszerelés megtörténik. Az összetétel két alapvető kategóriába sorolható: kliensoldali és szerveroldali.
Ügyféloldali összetétel: A webböngésző HTML-jelölés létrehozására és szerkesztésére szolgál. Mindegyik mikro-frontend képes megváltoztatni és külön megjeleníteni a jelölését az oldal többi részétől.
A webkomponensek például lehetővé teszik az ilyen típusú konstrukciók végrehajtását.
A terv az, hogy minden töredéket önállóan, a.js fájlként telepíthető webkomponensekké alakítanak, majd az alkalmazások betölthetik és a témaelrendezésben a számukra kijelölt helyeken renderelhetik azokat.
A webes összetevők a HTML és DOM API-tól függenek, amelyet más frontend keretrendszerek is használhatnak, valamint egy szabványos adatküldési és -fogadási módszertől kellékeken és eseményeken keresztül.
Szerver oldali összetétel: Ennél a kialakításnál az UI részek egyesülnek a szerveren, ami azt eredményezi, hogy egy teljesen kialakított oldal kerül a kliens oldalra, ami felgyorsítja a betöltést.
Az összeszerelést gyakran egy külön szolgáltatás végzi, amely a webböngésző és a webszerverek között helyezkedik el. A CDN a szolgáltatás egyik példánya (tartalomszolgáltató hálózat).
Igényeitől függően választhat a kettő közül az egyik vagy a kettő kombinációja közül.
Mikro frontend kommunikációs minták
A mikro-frontend architektúra akkor működik a legjobban, ha a különböző összetevők között alig vagy egyáltalán nincs interakció. A mikrofelületeknek időnként beszélniük kell egymással és meg kell osztaniuk az információkat. Íme néhány lehetséges minta, amelyek ehhez vezethetnek.
- Webmunkások: Az online dolgozó egy olyan mechanizmus, amely lehetővé teszi a webtartalom JavaScript futtatását a háttérben, más szkriptektől függetlenül, anélkül, hogy befolyásolná az oldal sebességét. Minden mikroalkalmazáshoz egyedi worker API-t biztosítunk. Ez az előny abban rejlik, hogy az időigényes munkát egy másik szálban is el lehet végezni, így az UI szál lelassítás vagy leállás nélkül folytatható.
- Eseménykibocsátó: Ebben az esetben sok összetevő úgy kommunikál egymással, hogy figyeli az előfizetett összetevők állapotváltozásait, és azokra reagál. Az adott eseményre előfizetett többi mikro-frontend válaszol, amikor egy mikro-előtét aktiválja az eseményt. Az egyes mikro-frontendekbe beépített eseménykibocsátó teszi ezt megvalósíthatóvá.
- Visszahívások és kellékek: Ebben a szakaszban definiálhat egy szülő- és egy utódkomponenst. A kommunikáció faszerű struktúrába szerveződik. A szülőkomponensek kellékeket használnak, hogy az adatokat függvényként továbbítsák az összetevőfán az alárendelt összetevőknek. A gyerek viszont hatékonyan riaszthatja a szülőt, ha bármi történik az állapotukban, reagálva a visszahívásokra. A React ezt a módot használja.
A Micro frontend előnyei
Fejlesztés gyorsan autonóm csapatokban
Egy független csapat létrehozhatja a webalkalmazások vagy webhelyek egyes részeit, ha mikro-frontend módszert használ.
Minden csapat teljesen autonóm, ami azt jelenti, hogy ő felel a teljes komponensfejlesztési ciklusért, a koncepciótól a kiadásig és az utógyártásig.
Ezenkívül ez azt jelenti, hogy a különböző csapatok zökkenőmentesen tudnak együttműködni, miközben egyidejűleg ugyanazon a projekten dolgoznak.
Ezért a kioldási ciklusok lényegesen gyorsabbak, mint a front-end monolitoknál.
Az egyéni mikro-frontendek kisebb kódbázisai tisztább kódhoz vezetnek
A monolitikus kezelőfelületek nagy, nehézkes kódbázisokkal rendelkeznek, amelyek kezelése idővel egyre kaotikusabbá és nagyobb kihívást jelent.
A mikro frontendek megoldják ezt a problémát. Mindegyik mikro-frontend forráskódja jobban kezelhető, mivel kisebb, egyszerűbb és kompaktabb.
Ennek következtében az általános webes megoldás tisztább kódot eredményez.
Továbbfejlesztett alkalmazásstabilitás a laza csatolás miatt
Egy webes megoldás ritkán osztható teljesen független darabokra. Következésképpen a mikro frontendek beszélnek egymással.
A komponensek közötti kapcsolat azonban a laza kapcsolat ellenére is jelentős.
Az egyik alkatrész meghibásodása alig, vagy egyáltalán nem befolyásolja az összes többi komponens működését, ami biztosítja a webes megoldás fokozott stabilitását.
Az egyes funkciók tesztelése egyszerűbbé válik
Ez az előny a mikro frontendek jellemzőiből fakad. Ezen építészeti tervezés alapján a webes megoldás ügyféloldala moduláris, és minden modul önálló.
Ennek eredményeként a felhasználói felület egy kis részének önmagában történő értékelése könnyebb egy csapat számára, mint egy hatalmas monolit tesztelése.
A csökkentett kötegméret gyorsabb oldalbetöltést eredményez
A funkciókban gazdag monolitikus webes rendszerekben a késleltetett betöltési idők egyik elsődleges oka a JavaScript-csomag mérete. Másrészt a mikro frontend megközelítés megkönnyíti az oldal betöltési idejének csökkentését.
A böngészőnek nem kell ismételten letöltenie a szükségtelen kódot, mivel egy weboldal több apró kötegből áll. Ennek eredményeként az oldal teljesítménye és betöltési ideje megnövekszik.
Technológiai függetlenség
Többszörös front-end keretrendszerek segítségével a fejlesztők egyetlen online megoldást hozhatnak létre mikro-frontend architektúrával.
Mivel minden komponens autonóm, a csapat feladataihoz legjobban illeszkedő technológia segítségével megépíthető.
Természetesen a programozóknak körültekintően kell eljárniuk az általuk irányított szoftverprojekt keretrendszerének kiválasztásakor, és továbbra is erősen tanácsos egyeztetni más csapatokkal.
Arra azonban nincs esély, hogy az alkalmazás élettartama alatt örökölt keretrendszert használjon.
A Micro Frontend hátrányai
Komplex webes megoldás tesztelése teljes egészében
Egy webes megoldás különféle moduljainak tesztelése egyszerű, ha mikro-frontend architektúrát használ. Ez azonban eltér egy webalkalmazás egészének értékelésétől.
A folytatás előtt ellenőrizze, hogy minden alkatrész rendeltetésszerűen működik-e. Ez nehéz lehet, mivel a mikro-frontendek függetlenül működnek, és külön szállítási folyamatokkal rendelkeznek.
Drága kezdeti beruházások
A mikro frontend fejlesztések általában jelentős pénzügyi ráfordítást igényelnek. Sok front-end csapat összeállítása és fenntartása költséges.
Ezenkívül vezetőségre lesz szüksége a munka megszervezéséhez, minden összehangoltsághoz, és garantálja a kiváló csapatkommunikációt.
A fejlesztés és telepítés összetettsége
A fejlesztési és telepítési eljárások bonyolultabbá válhatnak a mikro-frontend tervezés következtében.
A megoldást túl sok összetevővel zsúfolhatják össze például az ugyanazon a projekten dolgozó független fejlesztőcsapatok, ami problémákat okozhat a telepítési szakaszban.
Az összes modul megfelelő összeszerelése és zökkenőmentes integrálása a teljes rendszerbe szintén nem mindig egyszerű; ez a munka jellemzően szükségessé teszi az összes függőség alapos megértését.
Problémák a felhasználói élmény koherenciájának fenntartásával
A konzisztens felhasználói felület fenntartása kihívást jelent, amikor a csapatok külön-külön dolgoznak a szoftver több részén.
A webes megoldást a projekt összes fejlesztőjének meg kell osztania. Ellenkező esetben sok ellentmondás adódhat az úton.
Következtetés
A mikro-frontendek, egy kortárs építészeti tervezés, nagymértékben javíthatják a nagyszabású mikroszolgáltatás-alapú webfejlesztési projektek teljesítményét.
Lehetővé teszi a programozók számára, hogy a teljes megoldást különálló részekre ossza fel, amelyeket több önálló csapat is létrehozhat. Ebből számos előny következik, többek között a funkciók gyorsabb bevezetése, az egyes modulok egyszerűbb tesztelése és a zökkenőmentesebb frissítések.
De vannak nehézségek a mikro frontendekkel is.
Egy alkalmazás átfogó tesztelése például kihívást jelenthet.
Ezen túlmenően, mivel mérnökök és rendszergazdák nagy csapatára van szükség, a mikro frontend projektek nagyon drágák.
Következésképpen, mielőtt döntést hozna, figyelembe kell vennie üzleti ügyének minden elemét.
Vladimír Čamaj
Valahogy nem értettem, hogy milyen elven működik a kommunikáció az egyes komponensek között a frontenden. Nem értem, hogyan akarod összekapcsolni a különböző keretrendszerekben létrehozott komponenseket. A cikkben nincs róla szó. Az események és a hallgatóság rendszere számomra a földi pokolnak tűnik. Hogyan képzeljük el?