Luca Mezzalira 的 Smashing Podcast 第 6 集：什麼是微前端？

我們今年結束了另一個 Smashing 播客！ 這一次，我們將討論微前端。 什麼是微前端？ 它與我們目前可能採取的方法有什麼不同？ 讓我們從微前端先驅 Luca Mezzalira 那裡了解一下。

顯示註釋

每週更新

• “為 JAMstack 站點添加動態和異步功能，”Jason Lengstorf
• “UX 設計師的定量數據工具”，Adonis Raduca
• “為 Google Assistant 和 Amazon Alexa 創造語音技能”，Tris Tolliday
• “超越 Sprint 0：整合團隊的替代方案”，Shamsi Brinn
• “使用 CSS 包含屬性幫助瀏覽器優化”，Rachel Andrew

微前端

• Luca Mezzalira 的網站
• 盧卡在推特上
• “微前端，前端架構的未來” on Medium
• 更多 Luca 關於微前端的文章可以在他的 Medium 帳戶上找到
• Luca 的書《前端反應式架構》

成績單

Drew McLellan：他是 Google 的網絡技術開發專家和倫敦 JavaScript 社區的經理。 他擁有超過 15 年的經驗，目前擔任架構副總裁，設計體育視頻平台 DAZN，為數百萬觀看直播的用戶提供點播體育內容。 他是 Apress 的前端反應式架構一書的作者，也是 Apress、Packt Publishing、Pragmatic Bookshelf 和 O'Reilly 的技術審稿人，並且是世界各地技術會議上經驗豐富的公眾演講者。 他是意大利人，留著漂亮的鬍鬚，顯然對網絡平台有很深的了解。 但是你知道他曾經騎著鴕鳥穿越南美洲嗎？ 我的好朋友們，請歡迎 Luca Mezzalira。 嗨，盧卡。 你好嗎？

Luca Mezzalira：我太棒了。

Drew：我今天想和你談談微前端這個話題。 現在這對我來說是一個全新的概念，當然是名字，我希望它對我們的很多聽眾來說也是新的。 在我們進入微前端之前，我想我們應該了解您希望通過它們解決的問題。 所以也許你可以告訴我們一些關於你如何以更傳統的方式看待應用程序的問題，以及這些事情遇到了哪些問題，而微前端可能是解決方案？

Luca：好的，在我看來，這是一個很好的起點。 因此，通常當您實施或設計一個新的未開發項目並希望使用前端應用程序時，您可以利用一些架構。 您可以使用單頁應用程序，可以使用服務器端渲染應用程序，也可以使用僅由簡單 HTML 頁面組成的多頁應用程序。 顯然，這些是非常有效的選項，我認為許多開發人員都非常使用這些選項。 我們在這裡試圖解決的真正問題是，如何通過分佈式團隊將這些概念擴展到數百名使用同一代碼庫的開發人員，因為現實是當你在這些平台上工作時，尤其是當你考慮例如，SaaS 平台，您需要有多個開發人員和多個團隊在同一個項目上工作。 顯然，例如，您進行獲取或保留的方式與您展示目錄的方式或展示平台特定部分的方式完全不同。

Luca：所以根據我的經驗，我現在經常使用單頁應用程序。 我使用服務器端渲染應用程序，但在 DAZN 的某個時候，我被要求考慮一種擴展我們技術團隊的方法。 我需要提出……如果對於後端我們有一些解決方案，在這種情況下是微服務，所以我們可以獨立擴展我們的 API，並考慮到特定 API 上特定吞吐量的規模和數量。 在前端，真的，這真的更困難，因為如果你考慮一下，當你需要擴展時，你沒有技術問題需要解決，例如，如果你使用的是單頁應用程序。 可能對於服務器端渲染你有一些，但是在單頁應用程序上，例如，它是自然分佈的，因為它在客戶端，不同的客戶端。

Luca：所以他們加載的只是一些靜態文件，例如由 CDN 提供的 CSS、HTML 和 JavaScript，在這種情況下，您可以相應地進行擴展，這不是什麼大挑戰。 但真正的挑戰是如何擴展在同一平台上工作的團隊，因為有時一個團隊面臨的挑戰可能與另一個團隊面臨的挑戰完全不同，通常你所做的就是試圖找到很多事情之間的權衡。 因為如果你想，讓我們試著考慮一個正常的用例。 所以通常當你開始一個平台時，你從小處著手。 因此，您嘗試創建快速的單頁應用程序，以及您的單體應用程序，因此您只需為前端和後端設置一次 CICD 中的所有內容，然後開始迭代您的邏輯。 但現實情況是，當你取得成功時，你需要改進這部分，並且並不總是保持相同的架構，比如說，為你的業務創造利益，因為也許你會發現一些瓶頸。

Luca：所以現在回到單頁應用程序部分。 因此，如果我們想要擴展單頁應用程序部分，挑戰不在於技術，如果你願意，挑戰在於人類。 那麼我們如何擴展處理同一應用程序的團隊。 所以幾年前我所做的是，開始研究一種可能的架構和原則，使我能夠擴展前端和後端。 因此，研究後端原則，以便您可以找到微服務。 我開始研究不同的解決方案，他們推出了微前端，一開始我們甚至都沒有這樣稱呼它，因為很明顯在幾年前沒有那個特定架構的名字.

Luca：但現實是採用單體應用程序，即單頁應用程序並以一種允許我們專注於一個小問題的方式對其進行切片。 所以一個比整個應用程序更小的問題，並試圖以最好的方式解決這個問題。 從技術上講。 顯然，這會導致前端應用程序的獨立部分可以部署在生產中而不會影響所有其他應用程序。 所以微前端的挑戰基本上是試圖找出他們的方法來獲取單頁應用程序或服務器端呈現的應用程序並創建這些工件，比如說，盡可能接近業務域，並且可以獨立部署.

Drew：所以我的意思是你提到了後端的微服務。 所以從概念上講，這是一個類似的問題解決方案。 微服務服務於後端，但移植到前端。 這是一個粗略的等價，還是更多地參與其中？

盧卡：是的。 不，這是一種解決相同問題的方法，它試圖在後端解決微服務，但這次是在前端解決。 通常，當我一開始就開始這段旅程時，你會開始思考這個問題，並開始評估不同的方法。 在過去的幾個月裡，我提出了他們所謂的微前端決策框架，基本上是他們使用的四個步驟，假設你確定了微前端的方法，因為如果到目前為止，我們通常會選擇一個為我們設計架構的框架，然後我們在他們的架構之上實現。 如果您考慮 Angular 或考慮 React 或 Redux。 您擁有所有需要的部分，但您無需做出架構決策。 您將做出設計決策或如何在該特定架構之上實施。

Luca：所以在微前端你需要開始後退一步。 所以我們需要考慮如何首先對我們的應用程序進行切片。 因此，通常有兩種選擇。 您可以水平切片，因此您可以在同一個視圖中擁有多個微前端，也可以垂直切片。 因此，您每次總是加載一個微前端。 這些決定非常關鍵，因為它將根據最初的決定將您擁有的某些其他選項級聯起來。 所以首先，正如我所說，你決定你想如何分割你的應用程序。 第二個是您希望如何編寫應用程序。 因此，您希望擁有類似的應用程序外殼，它在同一視圖中加載一個或多個微前端。 我不知道，您想要擁有組成應用程序的不同片段的應用程序服務器，因此不同的微前端，然後將最終視圖提供給您的用戶。 或者您想使用包含的邊緣端，它是 CDN 內部的一個標準，用於編寫頁面並在那裡提供這些。

盧卡：這是您擁有的三個選項。 然後除了作曲之外，您還需要考慮如何路由。 因此，我不知道您如何從 /login 或 /signin 路由到目錄部分或特定的詳細信息對象。 同樣在這裡你有三個選項。 您可以在應用程序服務器上執行此操作，您可以在 CDN 級別使用 Lambda Edge 或 CloudFlare 中的任何其他網絡工作者或其他任何方式執行此操作。 或者你可以做一個客戶網站。 所以你在你的應用程序外殼中有一個邏輯，你說，好吧，現在對於這個特定的 URL，你需要加載另一個視圖或另一個微前端。 最後一點是您如何與微前端進行通信。

Luca：所以通常如果你在同一個頁面上有多個微前端，管理這種通信的複雜性更高，因為你需要保持不同的微前端獨立。 因此，這意味著您無法對頁面的結構有任何參考。 因此，通常您可以使用諸如自定義事件或註入到每個單個微前端中的事件計量器之類的東西。 然後微前端一起通信。 顯然，在另一種情況下，如果您喜歡說垂直拆分您的微前端更容易，因為在垂直內部基本上垂直微前端的表示是單頁應用程序或單頁。 在這種情況下，讓我們說創建和共享在整個微前端具有共享狀態會更容易。

Luca：那麼如果你考慮將多個微前端放在一起，那麼你應該避免在微前端之間共享狀態，否則你就是在耦合事物。 而不是這裡的整個概念是解耦並具有獨立部署。 因此，假設水平拆分（您應該做出的第一個決定或垂直拆分）的挑戰是完全不同的，我們需要非常清楚哪一個適合我們的用例。

Drew：因此，微前端不是一個特定的技術解決方案，而是非常類似於一種設計模式，您可以在適合您嘗試解決的特定問題的任何技術中實現它？

Luca：是的，不僅僅是技術，我認為我們會為正確的工作選擇正確的架構。 舉個例子，我在說……有一個著名的框架，一個相當新的微前端框架，叫做 Luigi 框架，它是由 SAP 開源發布的。 他們正在做的是創建一些 iframe，他們將微前端包裝在其中。 所以現在如果你考慮一下，比如說，現在使用 iframe，你在一個公共網站上，可能作為 SEO 或其他強制性功能，這可能是有問題的。

Luca：但就 SAP 而言，如果你考慮一下，他們有類​​似的企業應用程序，他們可以控制用戶正在使用的瀏覽器，他們可以控制環境，他們不需要在眾多或不同版本的瀏覽器。 所以對他們來說，這些東西允許他們擁有應用程序的某些區域是不變的，並且他們有某些區域可以獨立改變而沒有任何問題。 但顯然 iframe 解決方案在其他情況下不起作用。 再舉一個例子，Spotify，我們一開始就使用 iframe。 事實上，桌面出版物仍然由多個 iframe 組成，每個 iframe 都是一個很小的應用程序，我不知道它只是一個音樂播放器還是他們的推薦，不管它是什麼。 他們試圖在 Web 上採用相同的方法，但今年為了回到單頁應用程序而放棄了這種方法。

Luca：這意味著，他們解釋了為什麼在技術博客中，他們說如果您將其應用於使用 iframe 的數百萬用戶，這些用戶每次都需要加載相同的供應商文件。 然後你有很多重複的依賴項，與你的頁面交互的時間會更長。 所以實際上，這種方法可能適用於某些用例，但它們不應該適用於所有用例。 這就是為什麼我要說，正如我之前所描述的，如果你有一個決策框架可以幫助你解決這些問題，你可以開始說，好吧，我以這種方式分割應用程序，因此我有那些可用的選項當我想作曲，當我想路由，當我想交流時，它應該引導你，以便在正確的時間做出正確的決定。

Luca：那麼顯然除了這四個決定之外，還有很多其他的決定。 就像您如何在所有微前端的設計系統中創建一致性一樣。 或者我不知道您如何管理依賴項並避免微前端內部的依賴項衝突，但現實是我之前提到的這四個決定將允許您快速採取所有其他決定而無需過度思考的問題，這是最好的解決方案，因為您已經設定了基石，四大支柱，這將使您能夠做出所有其他決定……我說的不是簡單的方式，而是比審查更快的方式或機會的範圍。

Drew：您之前提到過，微前端可以幫助您組織內的團隊結構，並讓很多人在同一個應用程序上工作。 那麼有什麼影響？如果您的團隊分散或位於同一地點，或者那裡面臨任何挑戰，這有什麼不同嗎？

盧卡：是的。 所以我可以告訴你DAZN的故事是什麼。 這就是我正在工作的公司。 目前在 DAZN，我們遇到了一個不錯的挑戰。 所以目前我們有超過 300 人在我們平台的前端和後端工作。 這是一個 OTT 平台，可在全球體育賽事中進行直播。 有趣的是，如果我們或多或少地知道如何管理所有微服務，並且我們有分佈式團隊。 所以我們有四個開發中心。 我們希望將每個單獨的開發中心的團隊放在最前面，我們嘗試了這種方法並且效果很好。 因此，使用微前端，我們能夠在不同位置提供不同的業務領域，並允許特定業務領域內的團隊之間進行交叉通信，因為最糟糕的情況是，如果您必須與同一業務領域的另一個團隊交談，您只需步行即可到達辦公桌的距離。 相反，如果您需要在分銷團隊中討論具體的事情，那麼也許有人在倫敦而不是阿姆斯特丹，或者不是在波蘭的公司，您只需組織一次電話會議。

盧卡：但這種交流比在同一地點的團隊之間發生的交流更為罕見。 這就是我們開始研究的原因。 所以他們做的第一件事就是查看我們的用戶如何與我們的網站互動，公司的結構如何。 當我們確定我們正在研究的四個關鍵領域時，即目前的獲取和保留，假設將他們的核心應用程序移植到多台電視和移動設備上，並且我們的核心領域是視頻播放器和發現階段我們的內容。 最後是所有後台元素。 我能夠確定這四個區域，以及我們為每個開發中心分配的這四個區域。

Luca：顯然，這些領域之間存在一些聯繫點，但是您可以通過一些方法來減輕影響，並與位於不同地點的不同團隊進行一些初步研討會，然後製定相同的 API 合同，或者在開發過程中設置一些檢查點的目標相同。 但是允許使用微前端進行接近的好處是我們最終深入了解了我們的系統是如何工作的。 我們坐下來分析我們的結構，我們不僅改變了我們受到影響的方式，還改變了公司的運作方式。 這是一種與他們迄今為止所看到的不同的方法。 但事實證明，在每個團隊都可以與同一域中同一位置的團隊進行交互的情況下，這種方法非常有效。

Luca：所以如果你談論的是領域驅動設計，他們說的是完全一樣的語言。 也就是說，如果他們需要與其他團隊互動，他們可以直接共享工作室或飛往另一個開發中心，這不是問題。 但是通過這種方式，我們可以說，增加吞吐量並減少通信開銷，以及在他們正在處理的其他情況下發生的依賴程度。

Drew：所有這些團隊都需要像標準化的 JavaScript 框架一樣使用嗎？ 它們是否都需要編寫相同的代碼，它們都需要是 React 或 Angular，或者實現它們之間的互操作性，或者人們可以為不同的微前端使用不同的東西嗎？

盧卡：是的。 所以在 DAZN 中，我們決定垂直分割我們的微前端，這個決定讓我們可以自由選擇每個微前端所需的技術。 考慮到每次我們每次加載一個微前端時，這意味著例如，我們擁有登錄頁面的方式與登錄/註冊過程不同。 所以我們可以更新……我們目前主要使用 React。 但是，例如，如果我記得當 React 16 是我們能夠在生產中發布的 React 16 版本時，如果它不是在穩定版本中僅用於登錄頁面，並查看它是否可以正常工作而不影響所有其他球隊。

Luca：然後以他們自己的速度，以他們自己的節奏，他們正在更新他們自己的東西。 因此，這也讓我們可以假設我們在現有應用程序上擁有一定數量的用戶來嘗試新技術或新假設。 因為我們也為前端實現了候選版本。 我們實施了一些實踐，可以讓我們在生產中嘗試某些時間，看看事情是如何工作的。

Luca：這些方法的美妙之處在於，我們可以獨立決定為正確的工作使用正確的工具，而不是在整個堆棧中擁有一個共同點。 因為正如你可以想像的那樣，當你開始從事一個項目時，你最初幾年做出的決定可能與你在公司成長、業務發展和這些變得更加成熟的軌跡中做出的決定不同挑戰完全不同。 所以它不夠靈活或不夠敏捷，如果你考慮一下，我們堅持兩年前做出的相同決定這一事實。 特別是像 DAZN 這樣的機構，我們在三年內從基本零員工增加到 3000 名員工。 所以你可以想像這是一個巨大的增長，這對公司和用戶群來說都是一個巨大的增長。

Drew：不同的微前端是否有既定的方式來共享數據和相互通信，例如，只是為了讓彼此在同一視圖上保持同步，還是有辦法做到這一點？

盧卡：是的，有。 這取決於您將採用哪種決策框架，採用哪種路徑。 因為如果您要採用垂直切片，那將變得非常容易。 因此，為了通過微前端進行通信，我們所擁有的是一個應用程序外殼，它在自身內部的微前端中加載。 它所做的是存儲必須在不同的微前端或網絡存儲（會話或本地存儲或內存中）共享的所有內容。 然後基於這些信息，加載微前端，可以從應用程序外殼檢索到該信息，然後使用該信息，修改或更改它們。 這完全取決於您如何對應用程序進行切片，但在這種情況下，僅提供一個示例，如果您認為當您是經過身份驗證的用戶並且您需要轉到登錄頁面時，當您登錄和 API 是我們的消費和他們提供了一個 JWT 令牌，微前端將這些傳遞給應用程序外殼，而這些應用程序外殼開始我們保存了他們的 Web 存儲。

Luca：然後，在應用程序外殼為特定應用程序和那些已驗證的區域加載新的已驗證區域之後，它們從應用程序外殼檢索 JWT 令牌並執行刷新訪問令牌或驗證從內部開始的一些數據智威湯遜令牌。 所以它基本上使用了另一個微前端在他們自己的輪子上產生的信息。

Drew：這聽起來是一個非常有趣的概念，我可以潛在地看到以這種方式工作的許多巨大優勢，但它肯定不會沒有挑戰。 以這種方式構建事物時，是否有任何特定的事情更難處理？

盧卡：我認為首先我看到的主要挑戰是思維方式的轉變。 因為在我們習慣於有一個，比方說，技術負責人或主要開發人員圍繞整個應用程序決定一切，並做出所有決定。 現在，最後我們從這個中心化實體轉移到每個州本地的去中心化實體。 正如你可以想像的那樣，這帶來了一些挑戰，因為如果之前我們有人在跟踪路徑，現在我們有，比如說，在他們的領域內定義正確路徑的多個人，這是一個巨大的轉變的心態。

Luca：另一方面，我認為複雜性是接受有時你做錯誤的抽象可能比複製代碼更昂貴。 這就是我知道在管理開發人員時我發現有些事情非常具有挑戰性，因為他們在想，“好吧，現在我可以在項目中重複使用這個對像或這個特定的庫數百次”，但現實情況卻大不相同。 我看到了抽象的組件庫，他們花了很多時間將其打造為有史以來最好的代碼或完美形狀的最佳代碼。 但現實只用了兩次。 因此，這樣做的努力並不完全是那樣。 我在另一邊的庫中看到，他們從針對特定組件的幾個用例開始。 然後這些用例變成了 10 個，然後代碼變得無法維護。

Luca：因此，嘗試在同一個組件中添加新功能可能會帶來更多風險而不是好處。 所以我認為我們需要了解微前端的另一件事是我們想要分享多少以及我們想要復制多少。 老實說，複製並沒有什麼害處。 例如，在我們的例子中，我們有一個重複的頁腳和頁眉，我們這樣做主要是因為我們在四年內改變了三倍的頁眉。 所以你可以想像我們正在集中這些，被分配給一個團隊並為所有團隊創建一個外部依賴項，我們擁有的所有數百名開發人員，更讓我們說一個對公司有利的問題，因為我們沒有增加巨大的價值。

Luca：與此同時，我們正在重構我們的共享庫，即支付庫，因為顯然支付背後有一些邏輯，如果我們想更改一次，我們不想在多個部分應用兩次代碼。 我們只希望有一個作為事實來源的庫，但對於頁眉和頁腳，如果存在差異或像素或有一個函數在一周後部署，它不會傷害應用。

Drew：那麼，人們在評估應用程序並思考“哦，是的，這將是遷移到微前端類架構的一個很好的候選者”時，是否應該尋找一些明顯的跡象？

Luca：是的，所以我的建議是首先我不會用微前端開始一個新建項目，除非我們確切地知道它應該如何構建。 通常你不太可能擁有這些信息，因為，特別是如果你有一個新平台或一個新項目，而且這是你第一次從事這個工作，找到這些信息可能很不容易。 通常我的建議是從一個現有的架構開始，它是一個單頁應用程序，然後發展它。 特別是我發現，我認為將微前端用於遺留應用程序，或者當我們想要替換應用程序的特定部分時，或者當我們有一個想要為多個團隊發展和擴展的項目時，這三個用例我覺得很強大可以適應微前端架構。 顯然這並不意味著從現在開始一切都應該做微前端，因為微前端根本不是靈丹妙藥。

Luca：它們是一種額外的架構，我們可以在前端世界中加以利用。 到目前為止，我們已經有了一定數量的架構，現在我們有了額外的架構。 但這有很多挑戰，因為顯然你需要，如果在服務器端渲染或單頁應用程序之前，有明確的模式被探索然後由多個框架等實現。 目前使用微前端是一種做事方式。 但是添加決策框架可能應該允許人們為他們的用例做出正確的決定。 因為通常對什麼是微前端以及應該如何使用它們存在很多誤解。 很多人都在想，也許可以說，是邪惡的，我不知道，在一個視圖或其他東西中有太多的庫。

盧卡：現實情況是你需要深入理解這個概念，了解如何實現它，然後你就可以開始工作了。 我完全同意存在技術挑戰，並且您必須做出很多決定，您不能直接在您面前的編輯器開始編寫代碼並思考，好吧，現在我正在創建一個微前端建築學。 因為您需要了解概念、了解上下文並創建以及圍繞它進行治理，因為複雜性不僅僅是編寫代碼，還需要了解所有部分如何在 CICD 部分、SEO 部分等中組合在一起。

Luca：所以微前端確實提供了，比方說一定程度的靈活性，並且需要大量的努力來定義治理權。 因為當您擁有治理權時，一切都會順利進行。 不幸的是，我經常說，我看到公司沒有在治理方面花費足夠的時間，例如理解 CICD，因為他們認為這並不重要。 但是對於微前端，就像微服務一樣，擁有自動化權限可以讓您加快開發速度。 如果您沒有在自動化位上花費足夠的時間，那麼您的負擔可能會大於收益。

Drew：我想這就像 Web 開發世界中的許多事情一樣，人們在真正理解問題之前就有潛入技術解決方案的危險。 聽起來微前端非常需要您查看問題然後實施解決方案以了解您正在解決的問題。 我想微前端的本質使得開始集成到現有應用程序中變得非常容易，發現一個小問題並將其換成微前端以解決該問題。 這是一個合理的建議嗎？

盧卡：是的，我會這麼說。 在這種情況下，如果我們以這種方式開始，我唯一建議的就是更多地關注垂直切片而不是水平切片，因為否則你需要解決很多問題，假設你正在使用 Angular並且您想遷移到新版本的 Angular。 如果您需要在不使用 I-frame 的情況下讓兩個 Angular 版本同時存在，這可能會很複雜，甚至是不可能的。 所以如果你開始，你的方面不是從……如果你檢查挑戰，不是從技術的角度，而是從業務的角度。 也許例如，您可以使用（我不知道）您想要使用不同版本或相同版本但更多更新版本的框架編寫的登錄部分，這可能是一個好方法。 然後你通過路徑。 這可能是緩慢但穩定地替換特定應用程序的好方法。

Luca：在我們的案例中，我們所做的基本上是應用扼殺者模式，這是一種眾所周知的微服務模式，但在前端。 因此，基於 URL 並基於用戶的瀏覽器和國家/地區。 如此緩慢但穩定，基本上我們正在殺死單體，在這種情況下是單頁面應用程序，更頻繁地發布我們的新應用程序並查看用戶的行為，如果它改善了體驗，它會導致我們的系統出現任何問題或不。 這讓我們能夠為業務提供即時價值，但同時也讓我們能夠測試我們的假設，看看我們是否朝著正確的方向前進。

德魯：對於很多人都面臨的一些問題，這聽起來是一個非常有吸引力的解決方案。 如果我作為開發人員想開始更多地研究微前端，從哪裡開始比較好？

Luca：是的，所以目前我花了很多業餘時間嘗試圍繞這些架構進行宣傳，因為我認為存在很多誤解。 在我的中號帳戶上。 我寫了幾篇文章也可以在那裡找到。 A 錄製了很多會議視頻，您可以在 YouTube 上毫無問題地找到這些視頻。 如果你正在尋找一些框架上的代碼示例，我建議的另一件事是，我建議從單個 SPA 開始，主要是因為它具有垂直切片方法，更容易拿起它並且您可以開始了解這種架構的好處。 然後還有許多其他可用的。 Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.