關(guān)于web前端中微前端的誤解有哪些，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。
站在用戶的角度思考問題，與客戶深入溝通，找到秀英網(wǎng)站設(shè)計(jì)與秀英網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊(cè)、虛擬空間、企業(yè)郵箱。業(yè)務(wù)覆蓋秀英地區(qū)。
本篇文章給大家分享的是有關(guān)關(guān)于微前端的誤解有哪些，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
微前端是多年來追溯到的新趨勢(shì)。配備新的方式和解決挑戰(zhàn)，他們現(xiàn)在正在慢慢進(jìn)入主流。不幸的是，很多誤解都很明顯使得許多人難以掌握微抗議的困難。
簡而言之，微前端是關(guān)于將微服務(wù)的一些好處進(jìn)入前端。還有更多的是，一個(gè)人不應(yīng)該忘記微服務(wù)者沒有銀彈。
提示：要在微前端或任何其他項(xiàng)目之間共享React / Angular / Vue組件，請(qǐng)使用類似于位的工具。位允許您從任何代碼庫“收獲”組件，并將其與位為位的集合中。它使您的組件可用于您的團(tuán)隊(duì)，在任何回購中使用和開發(fā)。使用它來優(yōu)化協(xié)作，加速開發(fā)并保持一致的UI。
> Example: searching for shared React components in bit.dev
當(dāng)然，許多當(dāng)前可用的微前端解決方案是JavaScript框架。但這怎么可能是錯(cuò)的?JavaScript不再是可選的。每個(gè)人都想要高度互動(dòng)的體驗(yàn)，JS在提供它們時(shí)發(fā)揮重要作用。
除了給定的優(yōu)勢(shì)外，還應(yīng)考慮快速加載時(shí)間，可訪問的Web應(yīng)用程序和其他因素。因此，許多JavaScript框架提供了呈現(xiàn)成像的能力。最后，這導(dǎo)致不僅可以在客戶端縫合而且在服務(wù)器上準(zhǔn)備一切的能力。取決于所需的性能(即首次有意義的初始時(shí)間)此選項(xiàng)聽起來很可愛。
請(qǐng)記住，后端渲染具有自己的挑戰(zhàn)。
然而，即使沒有JavaScript解決方案的同構(gòu)渲染，我們也在這里處于良好狀態(tài)。如果我們想在沒有JavaScript的情況下建立微前端狀態(tài)，我們肯定可以這樣做。存在許多模式，并且它們的大量不需要JavaScript。
考慮“較舊”模式之一：使用
我聽到你笑了嗎?好吧，回到過去的日子里，已經(jīng)允許人們今天嘗試做的一些分裂(更多關(guān)于以下)。一個(gè)頁面(也許由另一個(gè)服務(wù)呈現(xiàn)?)負(fù)責(zé)菜單，而另一頁面負(fù)責(zé)標(biāo)題。
今天我們使用更靈活的(并且仍然積極支持)元素。它們提供了一些良好的能力 - 最重要的是他們互相屏蔽不同的微前端。通過PostMessage仍然可以進(jìn)行通信。
在JavaScript誤解之后，這是一個(gè)下一級(jí)。當(dāng)然，在客戶端的方面有多種技術(shù)來實(shí)現(xiàn)微前端，但實(shí)際上，我們甚至不需要任何或類似的方法來獲得微前端。
微前端可以像服務(wù)器端的“包括”一樣簡單。具有先進(jìn)技術(shù)，如邊緣側(cè)包括，這變得更加強(qiáng)大。如果我們想排除在微店段功能中實(shí)現(xiàn)的場(chǎng)景，那么即使是簡單的鏈接也很好。最后，微檔案解決方案也可以像微小，分離的服務(wù)器側(cè)渲染器一樣簡單。每個(gè)渲染器可以像單個(gè)頁面一樣小。
下圖說明了在反向代理中發(fā)生的更高級(jí)拼接。
> Server-side stitching via a reverse proxy
當(dāng)然，JavaScript可能有幾個(gè)優(yōu)點(diǎn)，但它仍然高度取決于您嘗試用微前端解決問題的問題。根據(jù)您的需求，服務(wù)器端解決方案可能仍然是最好的(或至少為更好的)選項(xiàng)。
在幾乎每個(gè)關(guān)于微前端的教程中，不同的部件不僅由不同的團(tuán)隊(duì)開發(fā)，而且使用不同的技術(shù)開發(fā)。這是虛假的。
是的，應(yīng)該使用不同的技術(shù)使用不同的微前端，但是，它不應(yīng)該是目標(biāo)。我們也不做微服務(wù)只是為了擁有真正的拼湊而成(或者我們應(yīng)該在我們的后端說“混亂”)。如果我們使用多種技術(shù)，那么只因?yàn)槲覀儷@得了特定的優(yōu)勢(shì)。
我們的目標(biāo)應(yīng)該永遠(yuǎn)是一定的統(tǒng)一。最好的方法是考慮一個(gè)綠色領(lǐng)域：那我們會(huì)做什么?如果答案是“使用單個(gè)框架”，我們就在正確的軌道上。
現(xiàn)在，在長期運(yùn)行中，多個(gè)框架在您的應(yīng)用程序中可能會(huì)變得顯而易見。它可能是由于遺產(chǎn)。這可能是一種方便。它可能是一個(gè)概念證明。無論原因是什么：能夠玩這種情況，仍然很好，但它永遠(yuǎn)不應(yīng)該是所需的狀態(tài)。
無論您的微前端框架有多效率 - 使用多個(gè)框架將始終以不可忽略的成本來實(shí)現(xiàn)。初始渲染不僅需要更長時(shí)間，但內(nèi)存消耗也會(huì)朝著錯(cuò)誤的方向邁出。便利型號(hào)(例如，某個(gè)框架的模式庫)不能使用。需要進(jìn)一步重復(fù)。最后，錯(cuò)誤的錯(cuò)誤，不一致行為和應(yīng)用程序的感知響應(yīng)性將受到影響。
一般來說，這并沒有很大的意義。我尚未看到一個(gè)服務(wù)器在一個(gè)服務(wù)中的微服務(wù)后端，并且API在另一個(gè)服務(wù)中。通常，服務(wù)包括多個(gè)層。雖然日志記錄等一些技術(shù)人員肯定會(huì)被帶到共同的服務(wù)，但有時(shí)會(huì)使用像邊車的技術(shù)。此外，還預(yù)期了服務(wù)內(nèi)的常見編程技術(shù)。
對(duì)于微前端，這是相同的。為什么一個(gè)微前端只能做菜單?不是一個(gè)菜單，每條微前端都是相應(yīng)填充的嗎?拆分應(yīng)由業(yè)務(wù)需求完成，而不是通過技術(shù)決策來完成。如果您讀過有關(guān)域驅(qū)動(dòng)的設(shè)計(jì)，您就知道它是關(guān)于定義這些域的所有域 - 以及此定義與任何技術(shù)要求無關(guān)。
考慮以下拆分：
> Decomposition into microfrontends by layout
這些是技術(shù)組件。這與Microfrontends無關(guān)。在真實(shí)的微前端應(yīng)用中，屏幕可能更愿意如下：
> Decomposition into microfrontends by domain
繪制的縫合在這里更復(fù)雜，但這是一個(gè)聲音微街的應(yīng)用程序應(yīng)該為您提供!
不。您應(yīng)該分享與共享有意義的原因。你絕對(duì)不分享一切(見下一個(gè)點(diǎn))。但要保持一致，您需要至少分享一組原則?，F(xiàn)在，如果是通過共享庫，共享URL，或只是在構(gòu)建或設(shè)計(jì)應(yīng)用程序時(shí)使用的文檔無關(guān)緊要。
對(duì)于微服務(wù)，這個(gè)“無共享”架構(gòu)看起來像下圖。
> “Share nothing” architecture applied to microservices
在瀏覽器中，這將導(dǎo)致使用，因?yàn)槟壳皼]有其他方法可以防止資源泄露?？梢愿綦x陰影DOM CSS，但腳本級(jí)別仍然能夠觸摸所有內(nèi)容。
即使我們想遵循架構(gòu)，我們將遇到麻煩。重復(fù)的資源只是為了保持簡單的組件活著將使感知性能癱瘓。
授予，共享更深是(例如，使用附加到DOM的共享庫)可能會(huì)出現(xiàn)問題。但是，另一方面，寬松的共享是(例如，只是一個(gè)指定基本設(shè)計(jì)元素的文檔)會(huì)產(chǎn)生的不一致。
絕對(duì)不。如果這是這個(gè)想法，那么一只巨石更有意義。表現(xiàn)明智這可能已經(jīng)是一個(gè)問題。我們懶得加載什么?我們可以刪除什么嗎?但實(shí)際問題是依賴管理。沒有什么可以更新，因?yàn)樗赡軙?huì)破壞一些東西。
共享零件的美是一致保證。
現(xiàn)在，如果我們分享一切，我們會(huì)引入復(fù)雜性以獲得一致性。但這種一致性是不可保持的，因?yàn)閺?fù)雜性將在每個(gè)角落都會(huì)引入錯(cuò)誤。
這個(gè)問題的起源在于“依賴地獄”。下圖略顯說明。
> Entering the dependency hell
簡而言之，如果一切都取決于我們有依賴問題的一切。只需更新單個(gè)盒子對(duì)整個(gè)系統(tǒng)產(chǎn)生影響。持續(xù)的?真的。簡單的?絕對(duì)不。
他們?yōu)槭裁匆礊槭裁?真的，到目前為止，我們大多觸及了網(wǎng)絡(luò)，但是可以將概念和想法帶到任何類型的應(yīng)用程序(移動(dòng)應(yīng)用程序，客戶端應(yīng)用程序，……，即使是CLI工具)。我看到它的方式微前端只是一個(gè)花哨的“插件架構(gòu)”的新詞。現(xiàn)在如何設(shè)計(jì)插件界面以及使用插件運(yùn)行應(yīng)用程序所需的內(nèi)容是一個(gè)不同的故事。
下圖顯示了相當(dāng)通用的插件架構(gòu)。信用進(jìn)入Omar Elgabry。
> Generic plugin architecture
沒有概念運(yùn)行在哪里。它可以在手機(jī)上運(yùn)行。它可以在Windows上運(yùn)行。它可以在服務(wù)器上運(yùn)行。
再次，為什么?如果解決方案是超級(jí)復(fù)雜的那么我肯定會(huì)尋找更簡單的。有些問題需要復(fù)雜的解決方案，但通常，一個(gè)很好的解決方案是一個(gè)簡單的解決方案。
根據(jù)場(chǎng)景，甚至可能甚至不需要分布式團(tuán)隊(duì)。分布式團(tuán)隊(duì)是微前端怪人首先有意義的原因之一，但它們不是唯一的原因。另一個(gè)好理由是特征的粒度。
如果您從商業(yè)角度查看微前端，那么您將看到有能力打開和關(guān)閉特定功能可能有意義。對(duì)于不同的市場(chǎng)，可以使用不同的微前端。已經(jīng)回到了一個(gè)簡單的特權(quán)級(jí)別這是有道理的。不需要編寫代碼以根據(jù)某個(gè)條件打開或關(guān)閉某些事項(xiàng)。所有這些都留給公共層，可以根據(jù)(可能的動(dòng)態(tài))條件來激活或停用。
這種方式可以(或應(yīng)該)不使用，也不會(huì)傳遞。雖然這不應(yīng)該是保護(hù)層，但它肯定是一種方便(和性能)層。用戶并不困惑，因?yàn)樗麄兯吹降闹皇撬麄兡茏龅氖虑?。他們沒有看到功能。該功能甚至沒有傳遞，因此在無法使用的代碼上沒有浪費(fèi)字節(jié)。
我擔(dān)心這是部分真實(shí)的，但一般來說，它不應(yīng)該是和(擾流器!)不必是。對(duì)于任何類型的實(shí)施(或符合論證的底層架構(gòu))，可以癱瘓發(fā)展經(jīng)驗(yàn)。戰(zhàn)斗的唯一方法是開發(fā)者 - 先。實(shí)施中的第一個(gè)規(guī)則應(yīng)該是：可以調(diào)試和開發(fā)。擁抱標(biāo)準(zhǔn)工具。
一些微前端框架根本不擁抱這個(gè)。有些需要在線連接，專用環(huán)境，多個(gè)服務(wù)，…這不應(yīng)該是常態(tài)。它絕對(duì)不是規(guī)范。
雖然結(jié)隔膜的模塊化后端可能是對(duì)前端解耦的良好基礎(chǔ)，但通常，這不是這種情況。它是完全可行的，可以具有要求模塊化前端的單片后端，例如，允許簡化個(gè)性化可能與授權(quán)，權(quán)限和市場(chǎng)相結(jié)合。
實(shí)際上，同樣的意義，微服務(wù)后端不僅僅是將類似模式應(yīng)用于前端的標(biāo)準(zhǔn)。許多微服務(wù)后端由不在功能中長大的單一目的應(yīng)用程序操作，而是僅僅發(fā)生了外觀。
幾次我已經(jīng)讀過它來創(chuàng)建一個(gè)微型狀態(tài)解決方案，可以利用Mono Repo，最好是使用Lerna等工具。我不相信。當(dāng)然，一個(gè)單一代碼倉有一些優(yōu)勢(shì)，但它們也有明確的缺點(diǎn)。
雖然有微型框架框架需要關(guān)節(jié)CI / CD構(gòu)建。聯(lián)合CI / CD構(gòu)建的要求通常導(dǎo)致單一代碼倉庫，因?yàn)槭紫纫獙⑵湓O(shè)置得更加簡單。但對(duì)我來說 - 這是重新包裝的巨石。如果您在單一代碼中有一個(gè)聯(lián)合版本，那么可以劃上兩個(gè)非常重要的因素，以便首先使微前端更有趣：
獨(dú)立部署
獨(dú)立發(fā)展
在任何情況下，如果您看到需要一個(gè)單代碼倉的微前端解決方案：運(yùn)行。在長期等待著等待的分布式系統(tǒng)的所有問題，精心制作的巨石可能更好。
monorepos / lerna的一個(gè)很好的替代方案是位。位允許您在存儲(chǔ)庫中協(xié)作組件 - 使團(tuán)隊(duì)能夠獨(dú)立提供功能。
微前端仍然不是每個(gè)人。我不相信微前端是未來的，但我也是他們?cè)谖磥戆l(fā)揮著重要作用的積極作用。
關(guān)于關(guān)于web前端中微前端的誤解有哪些問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。
重慶分公司
重慶分公司
