Rails,React,微服务和微前端

2021-01-08 22:15:26

开发人员之间的共同点是,我们花大量的时间安静地坐在电脑屏幕前,而脑袋里充满了内部状态。在Stitch Fix的样式小组中,我们正在朝着通过中央API连接使用微服务和微前端的应用程序体系结构的方向,减少开发人员在任何给定时间需要掌握的状态。

随着我们的应用程序的增长和变得越来越复杂,跟踪解决当前问题所需的所有思维线程变得越来越困难。正如我们的精神负担增加一样,我们的开发环境也变得越来越沉重。编写测试变得越来越困难,运行它们的速度也可能会变慢。 CI和部署时间逐渐增加。如果有多个团队参与构建一个应用程序,那么我们的整体将冒着对新的贡献者变得更加威吓的风险,并且我们必须严重依靠人际交流来填补空白。

我们认识到微服务不是万能药。这不是关于每个人都应如何转向微服务的博客文章。我们的动机既有组织性又有技术性。我们希望通过说明我们过去和将来的体系结构,您将能够使用我们的方法中与您自己的系统相关的部分。

我们的特定设置包括前端Web应用程序和相应的Rails后端。这给我们带来了很多好处!但这也带来了一些独特的挑战。当我们使用默认用于提供不同视图的后端框架时,与React的单页应用程序范型背道而驰可能特别诱人。

我们以前的体系结构由Rails视图和大型的整页React组件组成。我们有一些残留的Rails视图,这些视图提供HTML和原始JavaScript。这些观点是我们采用React之前的遗留物(白垩纪时代,如果您是React开发人员)。一旦React组件用完,它们便充当了自己的独立应用程序,对其连接的Rails层进行了基本的API调用。

与公认的模式不同意味着……您猜对了!需要传递更多的领域知识,并且在编程时要牢记更多。

当然,我们遇到了上一节中提到的问题。我们最近将新开发人员加入了我们的团队。随着她的开发环境的启动和运行,我们面对了一些挑战,如何直接进行整体设置。错误的依赖关系需要领域知识来进行追踪。为了使一件事情起作用,一切都必须起作用。那里有很多东西!我们的新体系结构旨在帮助其中一些障碍逐渐消逝。

但是,我们确实为我们的新架构奠定了基础:少数微服务使我们能够与组织内的其他服务进行对话。当我们过渡到新方法时,我们正在此基础上。

在事情的后端,我们开始广泛使用微服务。现在,我们将它们用于应用程序级和组织级需求。例如,我们正朝着提供全公司的商品销售和仓库服务的方向发展。我们的团队并不拥有这些,这给了我们更多的空间来成为我们领域的专家。我们计划开始向大型联合图过渡,工程组织中的许多团队也将使用此图。

就我们的React / Rails集成层而言,Rails仍然是我们的集中式API,前端可以通过它访问上述应用程序数据。现在,我们使用协定来验证前端和后端之间的契约。这样可以确保我们正在测试新分解的应用程序的接缝。 (这意味着我们更少依赖我们容易犯错的人作为我们合同的守望者!)

现在,我们的React用户界面已经与传统的Rails模型/视图/控制器模式脱钩了,我们有了更大的自由度,可以为他们提供成熟的应用程序。

我们简化了微前端的纺纱,以提高显影速度。我们有一个通过Create-React-App构建的议定入门应用程序。我们还在开发一个独特的,包含在内的组件库,以适合我们团队的特定专家使用需求。我们新的前端库利用带有语义版本的自动部署-我们获得了包含CI的好处,而没有整体的弊端。如果我们发现它可以共同改善我们作为开发人员的经验,则希望将其推广到我们其他一些现有的存​​储库中。

将功能性的,表示层的React组件提取到一个单独的库中,我们获得的另一个好处是,我们可以将它们与API隔离。现在,我们有了一个抽象的前端级别API层。它的唯一目的是管理从后端(在我们的契约发挥作用的地方)传入的数据。这是围绕领域知识提供系统支架的一种方法。

通过以这种方式对我们的前端和后端进行模块化,没有人会一直负责将整个应用程序保持在头脑中。作为开发人员,对我们更广泛的建筑生态系统有深刻的了解非常重要。当我们消除了“我需要知道它会如何运作,但足以让我在出现问题时将其挽救”的感觉时,我们便会为头脑空间提供便利,以便更深入地迭代团队的系统。