Мазмұны[Жасыру][Көрсету]
Микросервис идеясы жақында үлкен назар аударды және көптеген фирмалар оны үлкен, монолитті серверлерді жою үшін пайдаланады.
Веб-бағдарламалардың серверлік жағын құрудың бұл таратылған тәсілі зерттеу және орындау тұрғысынан аз немесе аз сенімді болса да, фронтпен бірдей бағытпен жүру әлі де көптеген бизнес үшін қиындық тудырады.
Өзінің тығыз тәуелділігіне байланысты клиенттік монолит әдетте жаңа мүмкіндіктерді біріктіруді, жаңа технологияларды қабылдауды және жеке құрамдас бөліктерді масштабтауды қиындатады.
Осы және басқа қиындықтар фронтенді әзірлеушілерді микросервистерді пайдалануды зерттеуге итермеледі.
Нәтижесінде веб-сайттар мен веб-негізделген қолданбалардың алдыңғы қабатын жасау үшін micro frontend деп аталатын жаңа архитектуралық стратегия әзірленді.
Бұл термин алғаш рет 2016 жылы қолданылды, содан бері ол жақсы мақсатта көп назар аударды.
Бұл мақала микро фронтендтер деген не және олар шешетін мәселелер туралы жалпы түсінік береді. ол жұмыс істейді, сонымен қатар жақсы және жаман жақтары бар.
Микро фронтальды архитектураға кіріспе
Микро фронтенд архитектурасы деп аталатын қазіргі заманғы интерфейсті әзірлеу әдісі a бөледі веб-бағдарлама шағын, тәуелсіз бөліктерге.
Түпкі пайдаланушыға бұл бөліктер тәуелсіз құрастырылып, содан кейін біріктірілсе де, бір бірлік болып көрінеді.
Микро фронтендтер желілік шешімдердің сервер жағына емес, клиенттік жағына қатысты айырмашылығымен, олардың негізінде жатқан негіздеме микросервистермен бірдей.
Күрделі веб-негізделген өнімдерді жасау микро фронтендтік тәсілді пайдалану кезінде ең мағыналы болады.
Кәдімгі алдыңғы қатарлы монолитке қарағанда микро фронтендтер көптеген командаларға әртүрлі бағдарламалық жасақтама жобаларында бөлек жұмыс істеуге мүмкіндік береді.
Бағдарламашылар осы архитектуралық дизайнды пайдалана отырып, веб-бағдарламаларды жылдамырақ және үлкен ауқымдылығымен және техникалық қызмет көрсету мүмкіндігімен жасай алады.
Қарапайым тілмен айтқанда, әрбір микро фронтенд веб-беттің нақты құрамдас бөлігі үшін кодтың бір бөлігі ғана.
Бұл мүмкіндіктерді әрқайсысы белгілі бір салаға немесе мақсатқа маманданған жеке топтар басқарады.
Монолитті және микросервистерге қарсы микро фронтенд архитектурасы
Көшіру туралы ойланыңыз. Сізге барлығын бірнеше кішкентай, білікті таңбаланған қораптарға бөліп, әрқайсысын жеке-жеке көшіру немесе бүкіл қызметкерлерді бір үлкен қорапқа жинап, жаңа орынға тасымалдау оңайырақ бола ма?
Айқын шешім сонда.
Бұл ұқсастық екі түрлі веб-бағдарлама архитектурасын, монолиттер мен микросервистерді (сонымен қатар микро фронттер ретінде белгілі) салыстырады.
Монолитті сәулет
Толық қолданба бір, біртұтас нысан ретінде жасалған «ескі күндерді» еске түсіре аласыз. Мұндай әдіс монолит деп аталады, бұл үлкен тас блок үшін ескі термин.
Бұл мағынасы бар.
Монолитті жүйелерде өзара тәуелді элементтер болады. Сондықтан, бірдеңені өзгерткіңіз немесе жаңа мүмкіндік қосқыңыз келсе, бүкіл жүйе бұзылуы мүмкін.
Ол ескіргенімен, кейде әлі де бар. Иә, біз сіздің қазіргі сөзіңізді білеміз.
Кодтық базаны екі түрлі құрамдас бөлікке концептуалды түрде бөлу - фронтенд (клиенттік) және серверлік (сервер жағы) - жаңа технологиялар дамып, бағдарламалық өнімдер күрделене түскен сайын сөзсіз болды.
Жұмыстың ең танымал әдісі - соңғы пайдаланушы әрекеттесетін презентация деңгейі мен фондық режимде орын алатын барлық нәрселер арасындағы алаңдаушылықты бөлу.
Оған екі бағдарламалық жасақтама командасы қажет, алдыңғы топ визуалды құрамдас бөліктерді құрастырады және веб-қызметтерді, бизнес логикасын, деректерге қол жеткізуді, интеграцияны және т.б. құрастырады.
Алайда, бұл бөлуге қарамастан, бұл стратегия әлі де табиғаты бойынша монолитті болып қала береді.
Негізгі өзгеріс мынада, бізде қазір бір үлкен қолданбаның орнына екі үлкен код блогы бар - алдыңғы және сервер. Монолитті архитектуралар қорқынышты болуы керек емес; олардың бірнеше артықшылығы бар, соның ішінде
- Бір бастапқы кодтық базасы және өте қарапайым дизайны бар шағын қолданбаларды қарапайым және жылдам әзірлеу;
- Тестілеу және жөндеу өте қарапайым, себебі барлық код бір жерде, бұл командаға сұрау ағынын бақылауды және қателерді анықтауды жеңілдетеді;
- Қолданбаны әзірлеудің басында шығындар арзанырақ, өйткені жаңа мүмкіндіктер қосылмайынша инфрақұрылымдық шығындар да, әзірлеу шығындары да алынбайды.
Бұл стратегияның кемшіліктері мынада көрсетілген
- Шектеулі орналастыру икемділігі – жобада олардың аз ғана бөлігі жұмыс істеп тұрса, командалар күтуі керек және кодты жаңартқан сайын жаңа орналастыру қажет болады;
- Жаңа технологияларды қабылдау өте қиын, өйткені бұл бүкіл жобаны болмаса да, маңызды бөлігін қайта жазуды қажет етеді.
- Әзірлеушілер саны көбейген кезде код жүйесі бір-бірімен тығыз байланысты, күрделі және басқару және түсіну қиынға соғады.
- Ұйымдастыру мәселелері – әрбір топ мүшесі кітапханалардың бірдей нұсқасын пайдалануы керек және көптеген топтар монолитті жобада жұмыс істеп жатса, кез келген өзгерістер туралы хабарлауы керек.
- Масштабтауға қатысты алаңдаушылық – жобаның құрамдас бөліктері бір-бірімен байланысты болғандықтан, оларды бөлек масштабтау айтарлықтай тоқтап қалуға және жоғары шығындарға әкелетін қиындықтарды тудырады.
- Жобаның күрделі логикасын команданың жаңа мүшелері түсінуі қиын болуы мүмкін, әсіресе онымен жұмыс істеген инженерлер енді жұмыс істемесе.
Микросервистердің және олардың жақын туыстарының және микро фронтендтердің дамуы монолитті жүйелердің негізгі мәселелерін шешті.
Микросервис архитектурасы
Микросервис деп аталатын архитектуралық әдіс қолданба серверін құрайтын көптеген еркін байланыстырылған және тәуелсіз орналастырылатын кішірек құрамдастарды немесе қызметтерді жасауға мүмкіндік береді.
Әрбір қызметте өзінің кодтық базасы, CI/CD құбырлары, DevOps процедуралары және оларды іске қосу процестері бар.
Жоғарыдағы суретке қарап, монолитті сервер тобының жеке топтарға бөлінгенін көруге болады.
Әрқайсысы қолданбаның басқа аспектісіне (мысалы, өнім қызметі, іздеу қызметі және төлем қызметі) жеке назар аударады.
Қызметтер арасындағы байланыс синхронды сұрау-жауап үлгілерін пайдаланатын жеңіл REST API протоколы сияқты API деп аталатын белгіленген протоколдар арқылы жүзеге асады.
Басқа нұсқа - байланыс құрылымдары мен оқиғаларын жариялау/жазылуды ұсынатын Кафка сияқты бағдарламалық жасақтаманы пайдаланып асинхронды байланысты пайдалану.
Микросервистер фронтенд (BFF) қызметке арналған сервер немесе желі арқылы API шлюзі арқылы фронтпен біріктіріледі. BFF әрбір клиент үшін теңшелген API ұсынады, ал API шлюздері микросервистердің жиыны үшін жалғыз кіру нүктесін береді.
Бірақ автономды сервер құрамдастарымен және олар беретін барлық артықшылықтармен бірге, фронтон әлі де монолит болып табылады.
Сондықтан бұл жерде микро фронттер пайдалы болады.
Микро фронтендтер архитектурасы
Бос байланыстырылған құрамдастарды бірнеше топ басқаратын микросервистерге ұқсас, микро фронтенд архитектурасы тұжырымдаманы браузерге қолданады.
Бұл веб-бағдарламаның пайдаланушы интерфейстері біршама автономды құрамдас бөліктерден тұратын осы құрылымды бақылайды.
Сондай-ақ командалар белгілі бір тәжірибе немесе технология емес, клиенттің қажеттіліктері немесе пайдалану жағдайлары бойынша құрылады.
Демек, командалар микросервистерге және микро фронтендтік жобаларға қатысады.
- тігінен кесілген — бір жобада жұмыс істейтін фронтенді әзірлеушілер, деректер сарапшылары, серверлік инженерлер, QA инженерлері және т.б. болғандықтан, олар өз мүмкіндіктерін келесіден жасайды. Қолданушы интерфейсі мәліметтер қорына; және
- кросс-функционалдық – әр топ мүшесі өз тәжірибесін топқа қосады.
Сондай-ақ командалар өздерінің нақты бизнес бағытына сәйкес келетін технологиялық стекті таңдай алады.
Бір команда өзінің фрагментін бағдарламалау үшін React пайдалана алады. Басқа топ жаңа бұрыштық нұсқаны жасайды. Vue.js - осындай мысалдардың бірі.
Микро фронтендтер әзірлеу топтарында әдетте монолиттермен байланысты мәселелерді шешу үшін қатысты микросервистермен бірге пайдаланылады. Стратегия келесі артықшылықтарды ұсынады.
- Технология еркіндігі: Frontend инженерлері компанияның қажеттіліктеріне байланысты балама JavaScript құрылымдарын, орындалу орталарын және бүкіл технологиялық стектерді таңдай алады. Ескірген архитектураның үстіне жаңа жақтау қолданылуы мүмкін.
- Үлкенірек икемділік дәрежесі мүмкін, өйткені әрбір микро фронтенд дербес және оны бөлек әзірлеуге, сынауға, орналастыруға және жаңартуға болады. Нәтижесінде, бір топ функциямен жұмыс істеп, қатені түзетсе, ал басқа топ өз мүмкіндігін қосуы керек болса, бірінші топтың өз тапсырмасын орындауын күтудің қажеті жоқ.
- Автономды топтар мен жүйелер: Әрбір өнім тобы, демек, әрбір мүмкіндік басқаларға аз тәуелділікпен жұмыс істей алады, бұл оған жақын маңдағы құрамдас бөліктер қолжетімсіз болған кезде де жұмысын жалғастыруға мүмкіндік береді.
- Бірнеше, кішірек код базалары: микро фронтендтердің әрқайсысының өзінің, басқарылатын, кішірек кодтық базасы болады. Аз адамдар белгілі бір UI құрамдас бөлігіне назар аударады, кодты шолуды жеңілдетеді және жалпы ұйымды жақсартады.
- Қарапайым қолданбаны масштабтау: микро фронтендтердің тағы бір артықшылығы - әрбір мүмкіндікті жеке масштабтау мүмкіндігі. Жаңа мүмкіндік қосылған сайын бүкіл бағдарламаны масштабтау қажет болатын монолиттерден айырмашылығы, бұл бүкіл процесті уақыт пен ақша тұрғысынан тиімдірек етеді.
Micro frontend қалай жұмыс істейді?
Біз бұрын айтқанымыздай, топтар микро фронтенд архитектурасында тігінен ұйымдастырылған, яғни олар домен білімі немесе мақсаты бойынша бөлінген және белгілі бір өнім үшін басынан аяғына дейін жауап береді.
Оның бір немесе екі серверлік микросервистері, сондай-ақ шағын фронтенді болуы мүмкін. Толығырақ, осы көрнекі элементтің сипаттамаларын, басқа UI құрамдастарымен өзара әрекеттесуін және басты бетке қосылуын қарастырайық.
Микро фронтенд болуы мүмкін
- тұтас бет (мысалы, өнім туралы толық бет) немесе
- беттің үстіңгі деректемелер, төменгі деректемелер және іздеу жолақтары сияқты басқа топтар пайдалана алатын бөлімдері.
Үлкен веб-сайтты бірнеше бет түріне бөліп, әр түрін жұмыс істеу үшін белгілі бір қызметкерге беруге болады.
Дегенмен, үстіңгі деректемелер, төменгі деректемелер, ұсыныс блоктары және т.б. сияқты көптеген беттерде бірнеше құрамдас бөліктер жиі кездеседі. Мысалы, ұсыныс блогын басты бетке, өнім туралы мәліметтер бетіне немесе тіпті тексеру бетіне қосуға болады.
Негізінде, командалар басқа командалар өз беттерінде пайдалана алатын бөліктерді жасай алады.
Микро фронтендтер, алайда, қайта пайдалануға болатын құрамдастарға қарағанда әртүрлі жобалар ретінде бөлек орналастырылуы мүмкін.
Мұның бәрі фантастикалық көрінеді, бірақ біртұтас интерфейсті жасау үшін беттер мен фрагменттерді қандай да бір түрде біріктіру керек.
Бұл маршруттауды, композицияны және байланысты қоса алғанда, әртүрлі стратегиялар арқылы жүзеге асырылуы мүмкін фронтендік интеграцияны қажет етеді (жоғарыдағы сызбаны қараңыз).
маршруттау
Бір топ басқаратын беттің қызметі басқа топқа тиесілі бетке кіру үшін қажет болғанда, маршруттау бет деңгейіндегі интеграция үшін пайдалы.
Әрбір микро фронтенд бір беттік қолданба ретінде өңделеді. Маршрутизацияны қамтамасыз ету үшін қарапайым HTML сілтемелерін пайдалануға болады.
Пайдаланушы браузерді серверден мақсатты белгілеуді жүктеп алуға және гиперсілтемелерді басу арқылы ағымдағы бетті жаңасымен ауыстыруға мәжбүрлей алады.
Қолданба қабығы - бұл UI-ге қуат беретін HTML, CSS және JavaScript-тің ең аз мөлшері. Серверден сұралған мазмұн деректері әлі күтіп тұрса да, пайдаланушы статикалық көрсетілетін бетті бірден алады. Орталық қолданба қабығы әртүрлі топтар жасаған бір беттік қолданбалар үшін негізгі қолданба ретінде қызмет етеді.
Пайдаланылып жатқан кітапханаға немесе фреймворкке қарамастан, мета фреймворктер әртүрлі беттерді бір бетке біріктіруге мүмкіндік береді.
құрамы
Композиция - бұл бөліктерді беттегі сәйкес бос орындарға орналастыру үшін орналастыру процесі. Көп жағдайда бетті орналастыратын топ фрагменттің мазмұнын бірден ала алмайды.
Оның орнына, ол фрагмент белгілеуде болуы керек жерде толтырғышты немесе маркерді орналастырады.
Басқа құрастыру процесін пайдалана отырып, соңғы құрастыру орындалады. Композицияны екі негізгі санатқа бөлуге болады: клиенттік және серверлік.
Клиенттік композиция: Веб-шолғыш HTML белгілеуін жасау және өңдеу үшін пайдаланылады. Әрбір микро фронтендтің беттің қалған бөлігінен бөлек белгілеуін өзгерту және көрсету мүмкіндігі бар.
Веб-компоненттер, мысалы, құрылыстың осы түрін орындауға мүмкіндік береді.
Жоспар - әрбір фрагментті a.js файлы ретінде дербес орнатуға болатын веб-компонентке айналдыру, содан кейін қолданбалар оларды тақырып орналасуында олар үшін белгіленген бос орындарға жүктеп, көрсете алады.
Веб-құрамдас бөліктер HTML және DOM API интерфейсіне тәуелді, оны басқа фронтендтік фреймворктар пайдалана алады, сонымен қатар деректемелер мен оқиғалар арқылы деректерді жіберу мен қабылдаудың стандартты әдісі.
Сервер жағындағы композиция: Бұл дизайнмен UI бөліктері серверде біріктіріледі, бұл толығымен қалыптасқан бет клиент жағына жіберіліп, жүктеуді жылдамдатады.
Жинау көбінесе веб-шолғыш пен веб-серверлердің арасында орналасқан бөлек қызмет арқылы жүзеге асырылады. CDN – қызметтің бір данасы (мазмұнды жеткізу желісі).
Сіздің қажеттіліктеріңізге байланысты біреуін немесе екеуінің комбинациясын таңдауға болады.
Микро фронтендік байланыс үлгілері
Микро фронтенд архитектурасы әртүрлі құрамдас бөліктер арасында өзара әрекеттесу аз немесе мүлдем болмаған кезде жақсы жұмыс істейді. Микро фронтендтер кейде бір-бірімен сөйлесіп, ақпарат алмасуы керек. Міне, соған әкелуі мүмкін бірнеше ықтимал үлгілер.
- Веб жұмысшылары: Желідегі жұмысшы веб-мазмұнға JavaScript-ті фондық режимде, басқа сценарийлерге тәуелсіз және бет жылдамдығына әсер етпестен іске қосуға мүмкіндік беретін механизм. Әрбір микро қолданба үшін бірегей жұмысшы API қамтамасыз етіледі. Бұл артықшылық уақытты қажет ететін жұмысты басқа ағында орындауға болады, бұл UI ағынын баяулатпай немесе тоқтатпай жалғастыруға мүмкіндік береді.
- Оқиға эмитенті: Бұл жағдайда көптеген құрамдас бөліктер өздері жазылған құрамдастардың кез келген күй өзгерістерін тыңдау және оларға әсер ету арқылы бір-бірімен байланысады. Осы нақты оқиғаға жазылған басқа микро фронтендтер микро фронтенд сол оқиғаны іске қосқанда жауап береді. Әрбір микро фронтендке енгізілген оқиға эмитенті мұны мүмкін етеді.
- Кері қоңыраулар және реквизиттер: Бұл бөлімде негізгі құрамдас пен еншілес құрамдастарды анықтайсыз. Байланыс ағаш тәрізді құрылымға ұйымдастырылған. Негізгі құрамдас бөліктер деректерді құрамдас ағаштан еншілес құрамдастарға функциялар ретінде жеткізу үшін тіректерді пайдаланады. Өз кезегінде, бала кері қоңырауларға жауап беру арқылы олардың күйінде кез келген нәрсе болған кезде ата-анасына тиімді түрде ескертеді. React бұл режимді пайдаланады.
Micro frontend артықшылықтары
Жылдам автономды командалардағы даму
Тәуелсіз топ микро фронтенд әдісін пайдаланған кезде веб-бағдарламаның немесе веб-сайттың әрбір бөлігін жасай алады.
Әрбір команда толығымен автономды, яғни ол тұжырымдамадан бастап шығаруға және өндірістен кейінгі кезеңге дейінгі барлық құрамдастарды әзірлеу цикліне жауап береді.
Сонымен қатар, бұл әртүрлі командалардың бір жобада бір уақытта жұмыс істеу кезінде үздіксіз жұмыс істей алатынын білдіреді.
Сондықтан босату циклдері алдыңғы қатардағы монолиттерге қарағанда айтарлықтай жылдамырақ.
Жеке микро фронтендтердің кішірек код базалары таза кодқа әкеледі
Монолитті алдыңғы бөліктерде уақыт өте келе ретсіз және басқару қиын болатын үлкен, қолайсыз кодтық базалар бар.
Микро фронтендтер бұл мәселені шешеді. Әрбір микро фронтендтің бастапқы коды басқаруға ыңғайлы, себебі ол кішірек, қарапайым және ықшам.
Жалпы веб-шешім таза кодтан пайда көреді.
Бос ілініске байланысты жақсартылған қолданба тұрақтылығы
Веб-шешім мүлдем тәуелсіз бөліктерге сирек бөлінуі мүмкін. Демек, микро фронтендтер бір-бірімен сөйлеседі.
Дегенмен, компоненттер арасындағы әрбір байланыс бос байланысқа қарамастан маңызды.
Бір құрамдастың істен шығуы веб-шешімінің жақсартылған тұрақтылығын қамтамасыз ететін барлық басқа құрамдастардың жұмысына аз немесе мүлдем әсер етпейді.
Жеке мүмкіндіктерді сынау жеңілдетілді
Бұл артықшылық микро фронтендтердің сипаттамаларынан туындайды. Осы архитектуралық дизайн негізінде веб-шешімнің клиенттік жағы модульдік және әрбір модуль автономды болып табылады.
Нәтижесінде, пайдаланушы интерфейсінің шағын бөлігін өздігінен бағалау үлкен монолитті сынаудан гөрі команда үшін оңайырақ.
Кішірейтілген бума өлшемі беттің жылдам жүктелуіне әкеледі
Мүмкіндіктерге бай монолитті веб-жүйелерде кешіктірілген жүктеу уақытының негізгі себептерінің бірі JavaScript бумасының өлшемі болып табылады. Екінші жағынан, micro frontend әдісі бетті жүктеу уақытын азайтуды жеңілдетеді.
Браузер қажет емес кодты қайта-қайта жүктеп алудың қажеті жоқ, өйткені веб-бет бірнеше шағын пакеттерден тұрады. Нәтижесінде бет өнімділігі мен жүктеу уақыты артады.
Технологиялық тәуелсіздік
бірнеше фронтальды жақтаулар оны әзірлеушілер микро фронтенд архитектурасы бар жалғыз онлайн шешімді жасау үшін пайдалана алады.
Әрбір құрамдас автономды болғандықтан, оны команданың міндеттеріне неғұрлым сәйкес келетін технологияның көмегімен жасауға болады.
Әрине, бағдарламашылар өздері басқаратын бағдарламалық жасақтама жобасы үшін негіздерді таңдағанда сақтық танытуы керек және басқа топтармен кеңесу әлі де қатаң түрде ұсынылады.
Дегенмен, қолданбаның қызмет ету мерзімі ішінде бұрынғы негізді пайдалануға мәжбүр болу мүмкіндігіңіз нөлдік.
Micro Frontend кемшіліктері
Толықтай кешенді веб-шешім сынағы
Веб-шешімнің әртүрлі модульдерін тестілеу ол микро фронтенд архитектурасын пайдаланғанда оңай. Бұл веб-қосымшаны тұтастай бағалаудан ерекшеленеді, дегенмен.
Жалғастырмас бұрын барлық бөліктердің жоспарланғандай жұмыс істейтінін тексеріңіз. Бұл қиын болуы мүмкін, өйткені микро фронтендтер дербес жұмыс істейді және бөлек жеткізу процестеріне ие.
Қымбат бастапқы инвестициялар
Микро фронтендтік әзірлемелер әдетте айтарлықтай қаржылық шығындарды талап етеді. Көптеген алдыңғы қатарлы командаларды жинау және ұстау қымбатқа түседі.
Бұған қоса, сізге жұмысты ұйымдастыру, барлығының үйлестірілгеніне көз жеткізу және тамаша командалық қарым-қатынасқа кепілдік беру үшін сізге басқарушы персонал қажет болады.
Әзірлеу мен орналастырудың күрделілігі
Әзірлеу және орналастыру процедуралары микро фронтенд дизайнының нәтижесінде күрделенуі мүмкін.
Шешімді бір жобада жұмыс істейтін тәуелсіз әзірлеу топтары тым көп құрамдас бөліктермен толтыруы мүмкін, мысалы, орналастыру сатысында қиындықтар тудыруы мүмкін.
Барлық модульдерді дұрыс құрастыру және оларды жалпы схемаға тегіс біріктіру әрқашан оңай емес; бұл жұмыс әдетте барлық тәуелділіктерді мұқият түсінуді қажет етеді.
Пайдаланушы тәжірибесінде үйлесімділікті сақтау мәселелері
Командалар бағдарламалық құралдың бірнеше бөліктерінде бөлек жұмыс істегенде, тұрақты пайдаланушы интерфейсін сақтау қиынға соғады.
Веб-шешім жобаның барлық әзірлеушілерімен ортақ болуы керек. Әйтпесе, жол бойында көптеген қайшылықтар болуы мүмкін.
қорытынды
Микро фронтендтер, заманауи архитектуралық дизайн, кең ауқымды микросервис негізіндегі веб-әзірлеу жобаларының өнімділігін айтарлықтай жақсарта алады.
Ол бағдарламашыларға толық шешімді бірнеше автономды командалар жасай алатын дискретті бөліктерге бөлуге мүмкіндік береді. Бұдан көптеген артықшылықтар пайда болады, соның ішінде функцияларды тезірек шығару, жеке модульдерді оңай сынау және үздіксіз жаңартулар.
Бірақ микро фронтендтерде де кейбір қиындықтар бар.
Мысалы, қолданбаны кешенді тестілеу қиын болуы мүмкін.
Бұған қоса, инженерлер мен әкімшілердің үлкен тобы қажет болғандықтан, микро фронтендтік жобалар өте қымбат.
Демек, шешім қабылдамас бұрын, сіз өз бизнесіңіздің барлық құрамдастарын ескеруіңіз керек.
Владимир Чамай
Фронттағы жеке компоненттер арасындағы байланыс қандай принцип бойынша жұмыс істейтінін түсінбедім. Мен әртүрлі шеңберлерде жасалған құрамдастарды қалай қосқыңыз келетінін түсінбеймін. Бұл туралы мақалада ештеңе жоқ. Оқиғалар жүйесі мен тыңдаушылар маған жердегі тозақ сияқты көрінеді. Оны қалай елестетуіміз керек?