更好的React/Rails架构

克莱尔·尼德伯格和马修·麦克米伦
——芝加哥,IL /小石城,AR

更好的React/Rails架构

我们开发人员的一个普遍现象是,我们每天花大量时间安静地坐在电脑屏幕前,脑子里充满了内部状态。在Stitch Fix的造型团队中,我们正在通过向使用微manbetx万博体育app 官方下载服务和微前端(通过一个中央API连接)的应用架构转变,减少开发人员在任何给定时间需要的状态量。

随着我们的应用程序的增长和变得越来越复杂,跟踪解决手头问题所需的所有心理线索变得越来越困难。正如我们的精神负担在增加一样,我们的开发环境也在增加。编写我们的测试变得更加困难,并且运行它们可能也会变慢。CI和部署时间逐渐增加。如果有多个团队参与构建一个应用程序,那么我们的庞然大物就会冒着让新贡献者更加害怕的风险,我们不得不严重依赖人类交流来填补空白。

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

我们以前的方法

我们的架构之前,

我们的特定设置由前端web应用程序和相应的Rails后端组成。这给了我们很多好处!但它也带来了一些独特的挑战。当我们使用默认提供不同视图的后端框架时,可能特别容易偏离React的单页面应用范例。

我们之前的体系结构混合了Rails视图和大型的全页面React组件。我们有一些残留的Rails视图提供HTML和普通的JavaScript。这些观点是我们采用React之前的遗留观点(如果你是React开发者的话,那就是白垩纪时代)。一旦React组件被提供,它们就像自己的离散应用程序一样运行,对连接的Rails层进行基本的API调用。

从被接受的模式发散意味着......你猜到了!需要通过的更多领域知识,并更多地记住您的编程。

当然,我们遇到了前一节中提到的问题。我们最近为我们的团队招募了一名新开发者。当我们启动并运行她的开发环境时,我们面临着设置一个庞然大物的一些挑战。错误的依赖关系需要领域知识来跟踪。为了让一件东西工作,所有的东西都必须工作。那里什么都有!我们的新架构旨在帮助一些障碍消失在过去。

不过,我们确实有一个新架构的踏脚石:一些微服务允许我们与组织内的其他服务进行交流。我们将在此基础上向新方法过渡。

我们要去哪里

我们的建筑演变

我们的后端

在后端侧的东西上,我们开始更广泛地使用微服务。我们现在使用它们来实现应用程序和组织级别的需求。例如,我们正在向拥有公司范围的商品和仓库服务迈进。我们的团队并不拥有这些,这使我们提供了更多的空间是我们域名的专家。我们计划开始向大型联邦图转移到整个工程组织中的许多团队也将使用。

就我们的React / Rails Integration Layer来说,Rails仍然是我们的集中API,我们的前端可以访问上述应用数据。我们现在使用契约验证前端和后端之间的合同。这使我们确保我们正在测试新分解应用的接缝。(这意味着我们依靠我们糟糕的人类自我依靠合同的守护者!)

我们的前端

既然我们的反应用户界面都与更传统的Rails型号/查看/控制器模式分离,我们有更多的自由来为他们提供作为全方形应用的房间。

我们已经简化了微前端的开发,以提高开发速度。我们有一个一致同意的启动程序,用Create-React-App构建。我们还在开发一个独特的、包含组件库的过程中,该组件库是为我们团队的特定专家使用需求量身定制的。我们的新前端库利用了语义发布的自动部署——我们获得了包含CI的好处,却没有单一集成的缺点。如果我们发现它整体上改善了我们作为开发人员的体验,我们希望将其推广到其他一些现有的存储库中。

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

的外卖

通过模块化我们的前端和后端,没有人需要一直把整个应用记在脑子里。作为开发人员,对我们更广泛的架构生态系统有一个强烈的认识是很重要的。当我们消除了那种“我需要知道这一切是如何运作的,但只是为了在它崩溃时我能够拯救它”的感觉时,我们便推动了我们的思维空间去迭代我们团队的系统。

这篇文章! 文章在LinkedIn
多线程

来吧我们!

我们是一支多元化的团队,致力于建立伟大的产品,我们喜欢你的帮助。你想用惊人的同伴建造惊人的产品吗?加入我们!