Гарчиг[Нуух][Үзүүлэх]
- Микро урд талын архитектурын танилцуулга
Micro frontend-ийн давуу тал +-
- Түргэн бие даасан багуудын хөгжил
- Хувь хүний бичил урд талын жижиг кодын суурь нь илүү цэвэр кодыг бий болгодог
- Сул холболтын улмаас програмын тогтвортой байдал сайжирсан
- Бие даасан шинж чанаруудыг турших нь илүү хялбар болсон
- Багцын хэмжээ багассан нь хуудсыг хурдан ачаалахад хүргэдэг
- Технологийн бие даасан байдал
- Дүгнэлт
Микро үйлчилгээний санаа сүүлийн үед олны анхаарлыг татаж байгаа бөгөөд олон пүүс үүнийг том, цул арын сүлжээг арилгахын тулд ашиглаж байна.
Веб программуудын серверийн талбарыг бүтээх ийм тархсан арга нь судалгаа, гүйцэтгэлийн хувьд бага эсвэл бага найдвартай байсан ч гэсэн урд талдаа ижил замаар явах нь олон бизнест сорилт хэвээр байна.
Үйлчлүүлэгчийн талын цул нь нягт хамааралтай байдаг тул шинэ функцуудыг нэгтгэх, шинэ технологи нэвтрүүлэх, бие даасан бүрэлдэхүүн хэсгүүдийг масштаблахад хэцүү болгодог.
Эдгээр болон бусад сорилтууд нь урд талын хөгжүүлэгчдийг микро үйлчилгээ ашиглан судлахад түлхэц болсон.
Үүний үр дүнд вэб сайт болон вэб-д суурилсан програмуудын урд талын давхаргыг бий болгохын тулд micro frontend гэж нэрлэгддэг цоо шинэ архитектурын стратеги боловсруулсан.
Энэ нэр томъёог 2016 онд анх хэрэглэж эхэлсэн бөгөөд түүнээс хойш сайн үйлсийн төлөө олны анхаарлыг татсан.
Энэ нийтлэлд бичил фронт гэж юу болох, тэдгээрийн шийдвэрлэх асуудлын талаар ерөнхий ойлголт өгөх болно. Энэ нь сайн болон сул талуудаас гадна ажиллаж байна.
Микро урд талын архитектурын танилцуулга
Микро фронтенд архитектур гэж нэрлэгддэг орчин үеийн орчин үеийн арга нь a вэб програм жижиг бие даасан хэсгүүдэд хуваана.
Эцсийн хэрэглэгчдэд эдгээр хэсгүүд нь бие даан бүтээгдэж, дараа нь нэгтгэсэн байсан ч нэг нэгж мэт санагддаг.
Микро фронтууд нь онлайн шийдлүүдийн серверийн тал биш харин клиент талтай холбоотой байдгийн ялгааг харгалзан тэдгээрийн үндэс суурь нь микро үйлчилгээнийхтэй адил юм.
Вэб дээр суурилсан боловсронгуй бүтээгдэхүүн хийх нь бичил урд талын хандлагыг ашиглахад хамгийн утга учиртай юм.
Микро фронтууд нь ердийн урд талын цул загвараас ялгаатай нь олон багийг янз бүрийн програм хангамжийн төслүүд дээр тусад нь хамтран ажиллах боломжийг олгодог.
Программистууд энэхүү архитектурын дизайныг ашиглан вэб програмуудыг илүү хурдан, өргөтгөх, засвар үйлчилгээ хийх боломжтой болгох боломжтой.
Энгийнээр тайлбарлавал, микро урд тал бүр нь вэб хуудасны тодорхой бүрэлдэхүүн хэсгийн кодын хэсэг юм.
Эдгээр онцлогуудыг тус бүр нь тодорхой салбар эсвэл зорилгод мэргэшсэн тусдаа баг удирддаг.
Монолит ба Microservices ба Micro frontend архитектур
Нүүлгэн шилжүүлэх талаар бодоорой. Танд бүх зүйлийг хэд хэдэн жижиг, мэргэжлийн шошготой хайрцагт хийж, тус бүрийг нь нүүлгэн шилжүүлэх эсвэл бүх ажилчдыг нэг том хайрцагт хийж, шинэ байршил руу зөөх нь танд илүү хялбар байх болов уу?
Тодорхой шийдэл тэнд байна.
Энэхүү зүйрлэл нь хоёр өөр вэб програмын архитектур, цул ба микросервисийг (мөн бичил фронт гэж нэрлэдэг) харьцуулдаг.
Монолит архитектур
Бүрэн программыг нэгдмэл, нэгдмэл байдлаар үүсгэсэн "хуучин сайхан өдрүүд"-ийг та санаж байгаа байх. Ийм аргыг монолит гэж нэрлэдэг бөгөөд энэ нь том чулуун блокийн хуучин нэр томъёо юм.
Энэ нь утга учиртай юм.
Монолит системүүд нь харилцан хамааралтай элементүүдтэй байдаг. Тиймээс, хэрэв та ямар нэг зүйлийг өөрчлөх эсвэл шинэ функц нэмэхийг хүсвэл систем бүхэлдээ эвдэрч болзошгүй.
Хэдийгээр хуучирсан ч гэсэн хааяа байсаар л байдаг. Тийм ээ, бид таны одоогийн илэрхийллийг мэдэж байна.
Кодын баазыг хоёр өөр бүрэлдэхүүн хэсэг болгон хуваах нь шинэ технологиуд хөгжиж, програм хангамжийн бүтээгдэхүүн илүү төвөгтэй болсон тул урд тал (үйлчлүүлэгч тал) ба арын хэсэг (сервер тал) нь зайлшгүй болсон.
Үйл ажиллагааны хамгийн түгээмэл арга бол эцсийн хэрэглэгчийн харилцдаг танилцуулгын давхарга болон арын дэвсгэр дээр болж буй бүх зүйлийг хооронд нь салгах явдал юм.
Үүнд програм хангамжийн инженерийн хоёр баг хэрэгтэй бөгөөд урд талын баг нь визуал бүрэлдэхүүн хэсгүүдийг, арын хэсэг нь вэб үйлчилгээ, бизнесийн логик, өгөгдөлд хандах, нэгтгэх гэх мэтийг бий болгодог.
Гэсэн хэдий ч энэ тусгаарлалтыг үл харгалзан энэхүү стратеги нь угаасаа цул хэвээр байна.
Гол өөрчлөлт нь бид нэг том програмын оронд урд болон арын хэсэг гэсэн хоёр том кодын блоктой болсон явдал юм. Монолит архитектурууд нь аймшигтай байх албагүй; зэрэг хэд хэдэн давуу талтай байдаг
- Нэг эх кодын сан, маш энгийн загвар бүхий жижиг программуудыг энгийн бөгөөд хурдан хөгжүүлэх;
- Туршилт, дибаг хийх нь маш энгийн бөгөөд учир нь бүх код нь нэг байршилд байгаа тул баг хүсэлтийн урсгалыг хянах, алдааг тодорхойлоход хялбар болгодог;
- Аппликешныг хөгжүүлэх эхэн үед шинэ боломжуудыг нэмэх хүртэл дэд бүтцийн зардал, хөгжүүлэлтийн зардал гарахгүй тул зардал хямд байдаг.
Энэхүү стратегийн сул талуудыг энд тусгасан болно
- Хязгаарлагдмал байршуулалтын уян хатан байдал - хэрэв төсөл дээр цөөн тооны хүмүүс ажиллаж байгаа бол багууд хүлээх ёстой бөгөөд кодыг шинэчлэх болгонд шинээр байршуулах шаардлагатай;
- Төслийг бүхэлд нь биш юмаа гэхэд нэлээд хэсгийг нь дахин бичих шаардлагатай тул шинэ технологи нэвтрүүлэх нь хэцүү байдаг.
- Хөгжүүлэгчдийн тоо нэмэгдэх тусам кодын систем нь хоорондоо нягт холбоотой, төвөгтэй, удирдах, ойлгоход хэцүү болдог.
- Зохион байгуулалтын асуудал - багийн гишүүн бүр номын сангийн ижил хувилбарыг ашиглах ёстой бөгөөд хэрэв олон баг цул төсөл дээр ажиллаж байгаа бол өөрчлөлтийг мэдээлэх ёстой.
- Өргөтгөх боломжийн асуудал – төслийн бүрэлдэхүүн хэсгүүд хоорондоо уялдаа холбоотой байдаг тул тэдгээрийг тусад нь өргөжүүлэх нь ихээхэн сул зогсолт, өндөр зардалд хүргэдэг хүндрэл үүсгэдэг.
- Төслийн нарийн төвөгтэй логикийг багийн шинэ гишүүд ойлгоход хэцүү байх болно, ялангуяа уг төсөл дээр ажиллаж байсан инженерүүд цаашид ажиллахгүй бол.
Микросервис ба тэдгээрийн ойр дотны хүмүүс, микро фронтуудыг хөгжүүлэх нь цул системүүдийн үндсэн асуудлуудыг шийдсэн.
Микро үйлчилгээний архитектур
Микро үйлчилгээ гэж нэрлэгддэг архитектурын арга нь програмын арын хэсгийг бүрдүүлдэг олон тооны чөлөөтэй холбогдсон, бие даан байршуулах боломжтой жижиг бүрэлдэхүүн хэсгүүд эсвэл үйлчилгээг бий болгох боломжийг олгодог.
Үйлчилгээ бүр өөрийн гэсэн кодын бааз, CI/CD дамжуулах хоолой, DevOps процедур, тэдгээрийг ажиллуулах процессуудтай байдаг.
Дээрх зургийг харахад цул арын баг нь тусдаа багуудад хуваагдаж байгааг харж болно.
Тус бүр нь програмын өөр өөр тал дээр (бүтээгдэхүүний үйлчилгээ, хайлтын үйлчилгээ, төлбөрийн үйлчилгээ гэх мэт) анхаарлаа хандуулдаг.
Үйлчилгээнүүдийн хоорондын холбоо нь API гэж нэрлэгддэг тогтоосон протоколууд, тухайлбал синхрон хүсэлт-хариултын загварыг ашигладаг хөнгөн REST API протоколоор дамждаг.
Өөр нэг сонголт бол харилцааны бүтэц, үйл явдлыг нийтлэх/захиалах боломжийг санал болгодог Кафка гэх мэт программ хангамжийг ашиглан асинхрон холбоог ашиглах явдал юм.
Бичил үйлчилгээнүүд нь урд талын (BFF) үйлчилгээний арын хэсэг эсвэл сүлжээгээр дамжуулан API гарцаар дамжуулан frontend-тэй нэгддэг. BFF нь үйлчлүүлэгч бүрт тохируулсан API-г санал болгодог бол API Gateway нь микро үйлчилгээний цуглуулгад хандах нэг цэгийг өгдөг.
Хэдийгээр бие даасан арын хэсгийн бүрэлдэхүүн хэсгүүд болон тэдгээрийн өгдөг бүх давуу талуудтай ч гэсэн урд тал нь цул хэвээр байна.
Тиймээс микро фронтууд нь энд ашигтай байдаг.
Микро урд талын архитектур
Сул холбосон бүрэлдэхүүн хэсгүүдийг хэд хэдэн баг удирддаг микро үйлчилгээтэй адил бичил урд талын архитектур нь уг үзэл баримтлалыг хөтөч дээр ашигладаг.
Эдгээр вэб програмын хэрэглэгчийн интерфэйсүүд нь бие даасан бүрэлдэхүүн хэсгүүдээс бүрдэх энэхүү бүтцийг дагаж мөрддөг.
Тодорхой туршлага, технологи гэхээсээ илүү үйлчлүүлэгчийн хэрэгцээ, хэрэглээний тохиолдлоор багууд байгуулагддаг.
Үүний үр дүнд багууд микро үйлчилгээ болон микро фронтенд төслүүдэд оролцдог.
- босоо зүсэгдсэн - нэг төсөл дээр ажиллаж байгаа урд талын программистууд, дата мэргэжилтнүүд, арын инженерүүд, чанарын хяналтын инженерүүд гэх мэт хүмүүс байдаг тул тэд өөрсдийн онцлогийг хэрэглэгчийн интерфэйс мэдээллийн сан руу; болон
- хөндлөн функциональ - багийн гишүүн бүр бүлэгт өөрийн мэдлэг, туршлагаа хувь нэмрээ оруулдаг.
Багууд мөн өөрсдийн бизнесийн салбарт хамгийн сайн тохирох технологийн стекийг сонгох боломжтой.
Нэг баг React-ийг ашиглан фрагментээ програмчилж болно. Өөр нэг баг шинэ Angular хувилбарыг бий болгодог. Vue.js нь ийм жишээ юм.
Микро фронтууд нь монолитуудтай холбоотой хөгжүүлэлтийн багуудад ихэвчлэн тулгардаг асуудлыг шийдвэрлэхийн тулд холбогдох микро үйлчилгээнүүдтэй хамт ашиглагддаг. Энэхүү стратеги нь дараах давуу талуудыг санал болгодог.
- Технологийн эрх чөлөө: Frontend инженерүүд компанийн хэрэгцээ шаардлагаас хамааран өөр JavaScript хүрээ, ажиллах орчин, технологийн бүхэл бүтэн стекийг сонгох боломжтой. Хуучирсан архитектурын дээр шинэ хүрээг ашиглаж болно.
- Микро урд хэсэг бүр нь бие даасан бөгөөд тусад нь хөгжүүлж, туршиж, байрлуулж, сайжруулж болох тул илүү уян хатан байх боломжтой. Үүний үр дүнд, хэрэв нэг баг функц дээр ажиллаж байгаа бөгөөд алдаа зассан бол өөр баг өөрийн гэсэн онцлогийг нэмэх шаардлагатай бол эхний баг даалгавраа дуусгахыг хүлээх шаардлагагүй болно.
- Автономит баг ба системүүд: Бүтээгдэхүүний баг бүр, улмаар онцлог бүр нь бусдаас бага хамааралтай ажиллах боломжтой бөгөөд энэ нь ойролцоох бүрэлдэхүүн хэсгүүд боломжгүй байсан ч үргэлжлүүлэн ажиллах боломжийг олгодог.
- Олон, жижиг кодын бааз: Микро урд тал бүр өөрийн гэсэн, илүү удирдах боломжтой, жижиг кодын сантай байх болно. Цөөн хүн тодорхой UI бүрэлдэхүүн хэсэг дээр анхаарлаа төвлөрүүлж, кодын тоймыг хялбарчилж, ерөнхий зохион байгуулалтыг сайжруулах болно.
- Энгийн програмын масштаб: Микро урд талын бас нэг давуу тал бол онцлог бүрийг тус тусад нь масштаблах чадвар юм. Шинэ функц нэмэгдэх бүрт програмыг бүхэлд нь өргөжүүлэх шаардлагатай цул хувилбаруудаас ялгаатай нь энэ нь бүх үйл явцыг цаг хугацаа, мөнгөний хувьд илүү үр дүнтэй болгодог.
Micro frontend хэрхэн ажилладаг вэ?
Өмнө дурьдсанчлан, багууд нь бичил урд талын архитектур дотор босоо байдлаар зохион байгуулагддаг бөгөөд энэ нь тэдгээрийг домэйны мэдлэг, зорилгоос хамааран тусгаарлаж, тодорхой бүтээгдэхүүнийг эхнээс нь дуустал хариуцдаг гэсэн үг юм.
Энэ нь нэг эсвэл хоёр арын микро үйлчилгээ, түүнчлэн жижиг урд талбартай байж болно. Энэ визуал элементийн шинж чанар, UI бусад бүрэлдэхүүн хэсгүүдтэй харилцах, нүүр хуудсанд оруулах талаар илүү дэлгэрэнгүй авч үзье.
Микро frontend байж болно
- бүхэл хуудас (жишээ нь, бүтээгдэхүүний дэлгэрэнгүй хуудас) эсвэл
- хуудасны толгой, хөл, хайлтын мөр зэрэг бусад баг ашиглаж болох хэсгүүд.
Та том вэбсайтыг хэд хэдэн төрлийн хуудас болгон хувааж, төрөл тус бүрийг тодорхой ажилтнуудад өгч болно.
Гэсэн хэдий ч толгой, доод хэсэг, санал болгох блок гэх мэт олон хуудсан дээр хэд хэдэн бүрэлдэхүүн хэсгүүд байнга гарч ирдэг. Жишээ нь, санал болгох блокийг нүүр хуудас, бүтээгдэхүүний дэлгэрэнгүй хуудас, тэр ч байтугай тооцооны хуудсанд багтааж болно.
Үндсэндээ багууд бусад багууд өөрсдийн хуудсан дээр ашиглах боломжтой хэсгүүдийг үүсгэж болно.
Гэсэн хэдий ч бичил урд талын хэсгүүдийг дахин ашиглах боломжтой бүрэлдэхүүн хэсгүүдээс ялгаатай нь өөр өөр төслүүд болгон тусад нь байрлуулж болно.
Энэ бүхэн гайхалтай сонсогдож байгаа ч нэгдсэн интерфэйсийг бий болгохын тулд хуудас, хэсгүүдийг ямар нэгэн байдлаар нэгтгэх хэрэгтэй.
Энэ нь чиглүүлэлт, бүтэц, харилцаа холбоо зэрэг янз бүрийн стратегиар хэрэгжиж болох фронтын интеграцийг шаарддаг (дээрх графикийг харна уу).
Чиглүүлэлт хийх
Өөр багийн эзэмшдэг хуудсанд хандахын тулд нэг багийн удирддаг хуудаснаас үйлчилгээ шаардлагатай бол чиглүүлэлт нь хуудасны түвшний интеграцчилалд ашигтай байдаг.
Микро урд тал бүрийг нэг хуудастай програм хэлбэрээр зохицуулдаг. Энгийн HTML холбоосыг чиглүүлэлт өгөхөд ашиглаж болно.
Хэрэглэгч хөтчөөс зорилтот тэмдэглэгээг серверээс татаж аваад гипер холбоос дээр дарж одоогийн хуудсыг шинээр сольж болно.
Програмын бүрхүүл нь UI-г идэвхжүүлдэг HTML, CSS болон JavaScript-ийн хамгийн бага хэмжээ юм. Серверээс хүссэн агуулгын өгөгдөл хүлээгдэж байгаа ч гэсэн хэрэглэгч статик харагдах хуудсыг шууд хүлээн авдаг. Төвийн програмын бүрхүүл нь янз бүрийн багуудын үүсгэсэн нэг хуудасны аппликейшнуудын үндсэн програм болж үйлчилдэг.
Ашиглаж буй номын сан эсвэл хүрээнээс үл хамааран мета-фрэймворк нь янз бүрийн хуудсыг нэг дор нэгтгэх боломжийг олгодог.
Найрлага
Зохиол гэдэг нь тухайн хэсгүүдийг хуудасны зохих зайд байрлуулах үйл явц юм. Ихэнх тохиолдолд хуудсыг байршуулсан баг фрагментийн агуулгыг шууд татаж авдаггүй.
Үүний оронд фрагмент нь тэмдэглэгээнд байх ёстой газарт орлуулагч эсвэл тэмдэглэгээг байрлуулна.
Өөр зохиох процессыг ашигласнаар эцсийн угсралт хийгдэнэ. Бүтэцийг хоёр үндсэн ангилалд хувааж болно: клиент талын болон сервер талын.
Үйлчлүүлэгч талын найрлага: Вэб хөтөч нь HTML тэмдэглэгээг үүсгэх, засварлахад ашиглагддаг. Микро урд хэсэг бүр өөрийн тэмдэглэгээг хуудасны бусад хэсгээс тусад нь өөрчлөх, харуулах чадвартай.
Жишээлбэл, вэб бүрэлдэхүүн хэсгүүд нь ийм төрлийн барилгын ажлыг гүйцэтгэх боломжийг олгодог.
Төлөвлөгөө нь фрагмент бүрийг a.js файл болгон бие даан суулгаж болох вэб бүрэлдэхүүн хэсэг болгон хувиргах бөгөөд үүний дараа программууд нь тэдгээрийг сэдэвчилсэн загварт заасан зайд ачаалж, дүрслэх боломжтой болно.
Вэб бүрэлдэхүүн хэсгүүд нь HTML болон DOM API-аас хамаардаг бөгөөд бусад фреймворкууд ашиглаж болохоос гадна тулгуур ба үйл явдлуудаар дамжуулан өгөгдөл илгээх, хүлээн авах стандарт арга юм.
Сервер талын найрлага: Энэхүү дизайны тусламжтайгаар UI хэсгүүдийг сервер дээр нэгтгэсэн бөгөөд энэ нь бүрэн үүссэн хуудсыг клиент тал руу илгээж, ачааллыг хурдасгадаг.
Угсралтыг ихэвчлэн вэб хөтөч болон вэб серверүүдийн хооронд байрладаг тусдаа үйлчилгээ гүйцэтгэдэг. CDN нь үйлчилгээний нэг жишээ (контент хүргэх сүлжээ) юм.
Та өөрийн хэрэгцээ шаардлагаас хамааран нэгийг нь эсвэл хоёрын хослолыг сонгож болно.
Микро урд талын харилцааны загварууд
Төрөл бүрийн бүрэлдэхүүн хэсгүүдийн хоорондын харилцан үйлчлэл бага эсвэл огт байхгүй үед бичил урд талын архитектур нь хамгийн сайн ажилладаг. Микро фронтууд хааяа хоорондоо ярилцаж, мэдээлэл солилцох шаардлагатай болдог. Үүнд хүргэж болох хэд хэдэн боломжит хэв маяг энд байна.
- Вэб ажилчид: Онлайн ажилтан нь вэб контентыг бусад скриптээс хамааралгүйгээр, хуудасны хурдад нөлөөлөхгүйгээр цаана нь JavaScript-г ажиллуулах боломжийг олгодог механизм юм. Микро апп бүрт өвөрмөц ажилчны API-г өгөх болно. Энэ давуу тал нь цаг хугацаа шаардсан ажлыг өөр хэлхээнд хийж, UI хэлхээг удаашруулж, зогсоохгүйгээр үргэлжлүүлэх боломжийг олгодог.
- Үйл явдал ялгаруулагч: Энэ тохиолдолд олон бүрэлдэхүүн хэсэг нь бүртгүүлсэн бүрэлдэхүүн хэсгүүдийн төлөв байдлын өөрчлөлтийг сонсож, түүнд нөлөөлөх замаар өөр хоорондоо харилцдаг. Тухайн үйл явдалд бүртгүүлсэн бусад микро фронтууд нь тухайн үйл явдлыг эхлүүлэхэд хариу үйлдэл үзүүлдэг. Микро фронтод бүрт нэвтрүүлсэн үйл явдал ялгаруулагч нь үүнийг хэрэгжүүлэх боломжтой болгодог.
- Буцах дуудлага ба тулгуур: Энэ хэсэгт та эх бүрэлдэхүүн хэсэг болон хүүхэд бүрэлдэхүүн хэсгүүдийг тодорхойлно. Харилцаа холбоо нь мод шиг бүтэцтэй зохион байгуулагдсан. Эцэг эхийн бүрэлдэхүүн хэсгүүд нь өгөгдлийг бүрэлдэхүүн хэсгийн модноос доош функц болгон хүүхэд бүрэлдэхүүн хэсгүүдэд дамжуулахын тулд тулгууруудыг ашигладаг. Хариуд нь хүүхэд эцэг эхийнхээ нөхцөл байдалд ямар нэгэн зүйл тохиолдоход буцаж дуудлагад хариу өгөх замаар үр дүнтэй анхааруулж чадна. React энэ горимыг ашигладаг.
Micro frontend-ийн давуу тал
Түргэн бие даасан багуудын хөгжил
Бие даасан баг нь микро урд талын аргыг ашиглахдаа вэб програм эсвэл вэбсайтын хэсэг бүрийг үүсгэж болно.
Баг бүр бүрэн бие даасан байдаг бөгөөд энэ нь үзэл баримтлалаас эхлээд хувилбар болон үйлдвэрлэлийн дараах бүхэл бүтэн бүрэлдэхүүн хэсгийн хөгжлийн мөчлөгийг хариуцдаг гэсэн үг юм.
Нэмж дурдахад энэ нь янз бүрийн багууд нэг төсөл дээр нэгэн зэрэг ажиллахын зэрэгцээ саадгүй хамтран ажиллах боломжтой гэсэн үг юм.
Тиймээс суллах мөчлөг нь урд талын цултай харьцуулахад хамаагүй хурдан байдаг.
Хувь хүний бичил урд талын жижиг кодын суурь нь илүү цэвэр кодыг бий болгодог
Цул урд хэсгүүд нь том, эвгүй кодын суурьтай бөгөөд цаг хугацаа өнгөрөх тусам эмх замбараагүй болж, удирдахад хэцүү болдог.
Микро фронтууд нь энэ асуудлыг шийддэг. Микро frontend бүрийн эх код нь жижиг, энгийн, авсаархан тул илүү удирдах боломжтой.
Үүний үр дүнд вебийн ерөнхий шийдэл нь цэвэр кодоос ашиг тус хүртдэг.
Сул холболтын улмаас програмын тогтвортой байдал сайжирсан
Вэб шийдэл нь бүрэн бие даасан хэсгүүдэд хуваагдах нь ховор байдаг. Үүний үр дүнд микро фронтууд хоорондоо ярьдаг.
Гэсэн хэдий ч, салангид холболттой хэдий ч бүрэлдэхүүн хэсгүүдийн хоорондох холбоос бүр нь чухал юм.
Нэг бүрэлдэхүүн хэсгийн эвдрэл нь бусад бүх бүрэлдэхүүн хэсгүүдийн үйл ажиллагаанд ямар ч нөлөө үзүүлэхгүй ба энэ нь вэб шийдлийн тогтвортой байдлыг хангадаг.
Бие даасан шинж чанаруудыг турших нь илүү хялбар болсон
Энэхүү ашиг тус нь бичил урд талын шинж чанараас үүдэлтэй. Энэхүү архитектурын дизайн дээр үндэслэн вэб шийдлийн үйлчлүүлэгч тал нь модульчлагдсан бөгөөд модуль бүр бие даасан байдаг.
Үүний үр дүнд хэрэглэгчийн интерфэйсийн багахан хэсгийг дангаар нь үнэлэх нь асар том цул туршилтаас илүү багийн хувьд хийхэд хялбар байдаг.
Багцын хэмжээ багассан нь хуудсыг хурдан ачаалахад хүргэдэг
Онцлогоор баялаг цул вэб системүүдийн ачаалах хугацааг хойшлуулах гол шалтгаануудын нэг нь JavaScript багцын хэмжээ юм. Нөгөөтэйгүүр, micro frontend арга нь хуудас ачаалах хугацааг багасгахад хялбар болгодог.
Вэб хуудас нь хэд хэдэн жижиг багцуудаас бүрддэг тул хөтөч нь шаардлагагүй кодыг дахин дахин татаж авах шаардлагагүй. Үүний үр дүнд хуудасны гүйцэтгэл болон ачаалах хугацаа нэмэгддэг.
Технологийн бие даасан байдал
Олон урд талын хүрээ микро фронтенд архитектур бүхий нэг онлайн шийдлийг бий болгоход хөгжүүлэгчид ашиглаж болно.
Бүрэлдэхүүн хэсэг бүр бие даасан байдаг тул аль технологи нь багийн даалгаварт хамгийн сайн тохирохыг ашиглан бүтээж болно.
Мэдээжийн хэрэг, програмистууд хариуцаж буй програм хангамжийн төслийн хүрээг сонгохдоо болгоомжтой хандах хэрэгтэй бөгөөд бусад багуудтай зөвлөлдөхийг зөвлөж байна.
Гэсэн хэдий ч, та програмын ашиглалтын хугацаанд хуучин тогтолцоог ашиглахаас өөр аргагүй болно.
Micro Frontend-ийн сул талууд
Вэб шийдлийн цогц туршилтыг бүхэлд нь
Вэб шийдлийн янз бүрийн модулиудыг турших нь бичил урд талын архитектурыг ашиглахад хялбар байдаг. Энэ нь вэб програмыг бүхэлд нь үнэлэхээс ялгаатай.
Үргэлжлүүлэхийн өмнө бүх эд анги нь зориулалтын дагуу ажиллаж байгаа эсэхийг шалгаарай. Микро фронтууд нь бие даан ажилладаг бөгөөд тусдаа хүргэх процессуудтай тул энэ нь хэцүү байж магадгүй юм.
Үнэтэй анхны хөрөнгө оруулалт
Micro frontend хөгжүүлэлт нь ихэвчлэн санхүүгийн ихээхэн зардал шаарддаг. Урд талын олон багийг цуглуулж, хадгалах нь үнэтэй байдаг.
Нэмж дурдахад, танд ажлыг зохион байгуулах, бүх зүйл уялдаа холбоотой байх, багийн харилцаа холбоог баталгаажуулах менежментийн ажилтнууд хэрэгтэй болно.
Хөгжүүлэлт ба байршуулалтын нарийн төвөгтэй байдал
Микро урд талын дизайны үр дүнд хөгжүүлэлт, байршуулах журам нь илүү төвөгтэй болж магадгүй юм.
Жишээлбэл, нэг төсөл дээр ажиллаж буй бие даасан хөгжүүлэлтийн багууд хэтэрхий олон бүрэлдэхүүн хэсгүүдээр шийдлийг гацааж, байршуулах үе шатанд асуудал үүсгэж болно.
Бүх модулиудыг зөв угсрах, тэдгээрийг ерөнхий схемд жигд нэгтгэх нь үргэлж энгийн байдаггүй; Энэ ажил нь ихэвчлэн бүх хамаарлыг сайтар ойлгохыг шаарддаг.
Хэрэглэгчийн туршлага дахь уялдаа холбоог хадгалахад тулгарч буй асуудлууд
Багууд програм хангамжийн хэд хэдэн хэсэг дээр тус тусад нь ажиллах үед хэрэглэгчийн тогтвортой интерфэйсийг хадгалах нь хэцүү байдаг.
Вэб шийдлийг төслийн бүх хөгжүүлэгчид хуваалцах ёстой. Тэгэхгүй бол зам дагуу зөндөө л зөрчил үүснэ.
Дүгнэлт
Орчин үеийн архитектурын загвар болох Micro frontends нь микро үйлчилгээнд суурилсан том хэмжээний вэб хөгжүүлэлтийн төслүүдийн гүйцэтгэлийг ихээхэн сайжруулж чадна.
Энэ нь програмистуудад бүрэн шийдлийг хэд хэдэн бие даасан баг үүсгэж болох салангид хэсгүүдэд хуваах боломжийг олгодог. Үүний үр дүнд функцийг илүү хурдан нэвтрүүлэх, бие даасан модулиудыг хялбархан турших, илүү саадгүй шинэчлэх зэрэг олон давуу тал бий.
Гэхдээ бичил урд тал нь бас зарим хүндрэлтэй байдаг.
Жишээлбэл, програмын иж бүрэн тест нь бэрхшээлтэй байж болно.
Нэмж дурдахад, инженер, администраторуудын том баг шаардлагатай байдаг тул бичил урд талын төслүүд нь өндөр үнэтэй байдаг.
Тиймээс шийдвэр гаргахаасаа өмнө бизнесийн бүх бүрэлдэхүүн хэсгүүдийг анхаарч үзэх хэрэгтэй.
Владимир Чамай
Ямар нэг байдлаар би урд талын бие даасан бүрэлдэхүүн хэсгүүдийн хоорондын харилцаа холбоо ямар зарчмаар ажилладагийг ойлгосонгүй. Янз бүрийн хүрээнд үүсгэгдсэн бүрэлдэхүүн хэсгүүдийг хэрхэн холбохыг хүсч байгааг би ойлгохгүй байна. Энэ тухай нийтлэлд юу ч байхгүй. Үйл явдлын систем, сонсогчид надад газар дээрх там шиг харагдаж байна. Бид үүнийг хэрхэн төсөөлөх ёстой вэ?