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.