React Native at Wix — The Architecture

React Native at Wix — The Architecture

Multi-Module Architecture

当您开发出一款出色的产品时，它会吸引越来越多的用户，而用户会寻求更多新功能并期望达到最佳性能。 在创业公司里，简单的React Native应用架构会很棒！只需很少开发人员工作在同一个代码库中，您可以通过这种方式来管理开发和发布过程，从而开发一项功能不会干扰继续同时在开发的另一项功能。

随着公司的发展和更多开发人员的加入，您仍然必须以与以前相同的速度交付功能-如果您坚持使用简单的应用程序结构，您可能会感到越来越难以快速迁移。 一个功能会破坏其他功能，构建过程也不再稳定，花费的时间还比以前更长，而且在单个代码库上一起工作越来越难。 如果您没准备好如何应对，那么代码质量将下降，最终将反映在应用程序质量中。 您和您的队友会因这种速度下降而感到沮丧，并且您可能会失去用户。

上面的示例可能适用于每个技术栈，但是使用React Native面临的情况更加复杂。 因为我们在3种不同的环境中工作：iOS，Android和JS，所以我们必须处理NPM，Gradle和CocoaPods。 为了发布一个用JS编写的小功能，所有团队成员都需要熟悉所有这些功能吗？ 好吧，不是这样的。

The Problem(s)

在Wix Mobile小组，我们会快速扩编。在短短几个月内我们将成员人数增加了三倍，并且是要在不影响我们的开发速度和应用质量的前提下实现增长，这使得我们必须思考如何另辟蹊径。

先让我们看一个简单的React Native应用程序结构：

在顶层，我们有我们的应用程序业务逻辑（红色），包括由JS和React编写的UI组件，实际上这是我们大多数代码库所在的位置。 在中间，我们具有React Native框架（紫色）作为与本地SDK的桥梁。 如果您想使用React Native中缺少的任何其他功能（例如，使用相机API，获取联系人或使用GPS），则应实现此缺少的功能，或者将外部库（橙色）作为项目添加到您的项目中。 依赖性。 此外，我们有JS库（黄色）作为实用程序（例如Moment，Lodash）或与您的Web项目通用的代码。

采用这种结构，你会在扩展功能时遇到许多不同的问题-常见问题可能与以下方面有关：

• Ownership所有权：代码所有权是指组织中的一个团队\一个人拥有一个codebase。 这个负责者要管理代码更改，做出有关设计的决策以及处理bug。 在单个项目中，Ownership应得到很好的定义，但是使用简单的应用程序结构（单一代码库）时，这个边界其实并不明确。
• 速度：对于开发人员而言，开发和发布速度都极为重要。 由于React Native项目在同一项目中包含Native和JS代码库，因此即使我们对JS进行了很小的更改，它也迫使我们一次又一次地编译和构建整个native项目。 我们应该努力在每个团队中进行完全独立的开发，只构建团队负责的代码，并获得所有其他依赖关系作为预构建（pre-build）； 无需重建未修改的native代码。
• 测试：与其他50位将代码推送到您的存储库的开发人员一起测试您的功能和代码变得很困难。 每个团队都有自己的测试技术和实践，因此没有理由将所有应用程序测试都放在同一位置。 能够测试以隔离方式更改的最小代码段，而不依赖于其他代码，这更有意义。

一旦意识到了所有这些并了解了我们的发展速度，我们得出的结论是，用简单的React Native应用程序结构将无法实现我们的梦想。

The Solution

设计架构时，它应适合您的组织结构。

Wix Organizational Structure

Wix分为多个实体，每个实体都称为Company。每个Company都是面向产品的实体，致力于特定产品的一系列功能。 例如：

• WixStores处理在线商店所需的所有功能，例如目录，价格，交货等。
• WixMedia可用于与Wix用户的媒体需求相关的所有功能，例如将图像保存到站点，编辑视频以及广播视频或音乐等。

您可以将每个company视为一家功能齐全且独立的初创公司。 此外，我们还有一个名为** Guild **的专业机构，该机构根据员工的专业知识对其进行分组。 例如，我们有一个Server Guild，一个Mobile Guild，一个QA Guild等等。 每个Guild负责根据需要雇用，教育和调整其开发人员。 该结构旨在确保我们可以作为独立的团队快速行动，而不是与其他团队争夺资源。

除此之外，有些Company还拥有全栈开发人员，他们从数据库到用户界面端到端开发其功能，因此他们可以为移动应用做出贡献，而无需任何native（iOS \ Android）经验。

Our Goals

考虑到以上所有因素，我们为新架构定义了以下目标：

1. 独立开发：通过隔离的团队，可以将每个团队的代码库开发和测试为一个黑盒子，但是具有相同的基础架构。
2. 独立部署：这使每个开发人员都可以像Web开发人员一样，将新功能尽快发布到生产环境中。 这是朝着真正的连续部署迈出的又一步，目前在移动设备上是不可能的。
3. 无需Native知识依赖：在Wix，与移动开发人员相比，我们拥有更多的Web开发人员。 我们的目标是完全不需要原生知识（无需打开Xcode来检查iOS设备上的功能）。
4. **稳定的基础代码作为依赖项：**为了最大程度地减少我们日常工作中的干扰，开发人员应该能够在使用生产基础代码的同时进行开发，而不必依赖仅针对DEV时间开发的特殊代码（示例项目）。

Multi-Module Architecture

单体模式不适用于大型项目

对于大型移动应用程序采用单体模式变得笨拙。 需要一种将其分解为可以独立运行的较小模块的方法。

多模块体系结构背后的想法是将应用程序视为独立团队拥有的功能组合。 每个团队都有自己专注和擅长的业务领域和任务。

您也可以将其视为一个操作系统（OS）和应用程序-每个团队都有其自己的使命，并且所有团队功能（迷你应用程序）都捆绑在基于同一OS的单个应用程序中。

How Does it Work?

此任务成功的关键是关注点分离。后端开发人员将其称为微服务，前端开发人员对其进行扩展，并发明了微前端架构。 这种分离可以以不同的方式进行，垂直（按feature）或水平（按layer）-我们决定混合使用这两个维度。

试想，您的应用程序代码库包括这样两部分：一部分是所有团队都使用的基础结构，很少更改，发布周期不同，需要大量的测试，并且对更改更敏感。而另一部分，是由多个团队开发的产品业务逻辑本身（即UI组件），面向用户的流程具有更快的发布周期，大多数情况下彼此无关，因此可以将其称为应用程序的“扩展”。

考虑到这一点，我们将代码库分为两个主要实体：Engine和Modules。

Engine

Engine部分将我们的React Native应用程序的所有基础设施包装到一个包中。

Engine包括iOS和Android的native项目，React Native框架，具有本机代码的所有第3方库以及任何JS基础结构代码。

• Engine就是我们应用程序的操作系统。
• 这是应用程序的入口点-当应用程序打开时，第一行代码是该项目的*** index.js***。
• Engine为所有为该应用程序开发的开发人员提供了所有基础结构（推送通知，错误处理，网络层，本地化，可访问性等），因此他们可以专注于编写产品。
• Engine由一个单一的基础架构团队开发，包括高级Native开发人员以及熟悉React Native底层工作原理的专家。
• 由于Engine负责提供整个native代码，因此可以将其作为已编译的可执行程序包（APK，APP）提供。

上面的最后一点是我们架构中最重要的部分，Engine保存了应用程序的二进制文件，因此其他项目可以将其添加为依赖项，在设备上安装预构建的app，但要加上自己的JS代码。

如果您问自己“ 怎么可能？！” ，请继续阅读。

Modules

如前所述，在Wix，我们分为独立工作的小型产品组（Company），这导致我们将JS层划分为较小的部分，由一个单独的团队开发和维护。

• Module是Wix应用程序内部的一个微型应用，封装了独立的产品业务逻辑。
• Module仅用JS（或TS）编写，无任何本机代码。 该团队不需要Native开发人员。
• 当然，即使Module实现了不同的产品，Module之间也可以相互通信，但我们有大量的集成工作。 例如，一个Module作为整个应用程序的“settings service”，所有其它Module都可以使用它来访问用户信息等数据。如此等等。Module的开发过程应独立的事实，不应以任何方式限制产品
• 每个Module都应实现一个接口，作为其与Engine和其他Module的约定。
• Module可以具有JS库作为依赖项，它们可以是utils库，Module之间的的共享代码，或者App与Web之间的共享代码。
• Module将Engine基础结构作为一个服务。
• Module作为软件包发布到NPM（到私有注册表）。

The New Structure

Multi-Module Architecture

现在，在我们熟悉Module和Engine之后，让我们谈谈它们如何共同运作？

在上图中，您可以看到实体的3种类型：Engine，Module和Wix App。

Wix App是主要存储库，其中包括对我们所有Module和Engine的依赖关系。 实际上，Wix App存储库只是一个配置文件和依赖项列表，并且不包含任何代码。 该应用程序的入口点是Engine *** index.js \ ***，它从项目的根文件夹中读取配置文件以及所有Module的列表。

我们所做的最大更改是从主存储库预构建出APK/APP放入一个单独的项目中，以允许开发人员使用同一个Native项目运行应用程序中属于自己的部分。 这个概念类似于专门为Wix量身定制的[Expo]（https://expo.io/），因此Wix Module不是从应用商店下载Expo应用，而是从Engine获得获取所依赖的APK / APP文件。 通过这种方法，所有团队都可以获得“相同的Native环境”进行开发，而Module的开发人员无需接触任何本机代码，从而节省了构建和集成Native代码的时间。

如果Module的开发人员需要使用Native依赖，则应要求Engine团队将其添加或PR到Engine项目。 实际上，这种方法会打破了所有权边界，但是它可以帮助我们减少构建时间，由Native开发人员仔细检查具有Native代码的库，并解决不同Module使用不同Native版本的问题。

Communications

Module可以在它们之间进行通信和传输数据，但是所有通信都是通过Engine进行的。

Module之间没有直接通信，Module之间也没有直接依赖，以便控制内部通信，添加约定验证并支持Module的延迟加载，因此Module代码不会加载到内存中，直到另一个Module请求它。通信渠道多种多样，Module可以暴露供其他Module使用的功能和组件，甚至可以相互监听广播事件。

Release Cycles

由于Engine和每个Module都在单独的代码库中开发并作为不同的NPM软件包发布，因此它们每个都有不同的发布周期。

在我们的案例中，每两周发布一次新的Engine版本，因为它包含影响大的基础结构代码，并且需要大量的QA。 但是Module的所有者几乎每天都发布一个彼此独立的新版本。 这种方法从根本上与微服务相同，只是独立释放代码的一小部分。

将新的Wix App版本发布到商店后，便会构建该应用程序并将其与所有Modules和Engine的最新稳定版本捆绑在一起。 我们目前在应用程序中拥有40多个由不同的团队开发的Module。

Results

就目标而言，正如我们在本博文前面所定义的那样，我们基本上实现了所有目标（甚至更多）：

1. 独立开发：每个团队（Company）可以为其自己的功能集创建一个新模块，可以对代码进行测试而不会被其他人破坏。

2. 独立部署：您随时可以发布模块的新版本，而无需担心其他团队是否准备就绪。

3. Web开发人员>移动开发人员：完全不需要了解本机的好处–无需在本地上构建Native项目，它已经为您准备好了。

4. 完全相同的开发-生产环境：所有团队都工作在相同的Native环境上，不论是开发环境还是生产环境。

5. 更轻松的React Native升级：只需一个团队维护本地项目和应用程序的基础架构，升级到更新的React Native版本就容易得多。 如您所知，React Native可以为新版本进行许多重大更改，但是现在大多数更改是在引擎中进行的，而不会打扰模块所有者的日常工作。 在许多情况下，重大更改是由Engine的API处理和封装的，因此升级对开发人员而言是透明的。

6. 不同的发布过程：由于引擎是唯一包含本机代码的部分，因此我们可以通过两种方式更新生产中的代码：每次模块发布新版本时，OTA（通过空中传输），或提交 新App \ APK到AppStore和GooglePlay，以获取新的Engine版本（更改了本机代码）。

Wrap Up

单独实现一个新架构是一个巨大的挑战，我们面临很多挑战，但是最后，在我们的React Native应用程序中采用Multi-Module架构是一个巨大的成功。

我们的组织结构和Multi-Module架构，改变了Wix Mobile的开发文化。 没有专门的iOS或Android团队，而且我们有Web工程师定期将代码发送到我们的移动应用程序，而几乎不需要Native工程师手动操作。 我们允许团队一方面拥有自由，另一方面拥有统一的产品，用户界面和基础架构，即使是由世界各地的不同开发人员开发的。

原文地址

React Native at Wix – The Architecture