Rails，React，微服务和微前端

开发人员之间的共同点是，我们花大量的时间安静地坐在电脑屏幕前，而脑袋里充满了内部状态。在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层。它的唯一目的是管理从后端（在我们的契约发挥作用的地方）传入的数据。这是围绕领域知识提供系统支架的一种方法。

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