时间戳

首页 > 解决方案 > 如何设计前端来处理多个后端版本

spring - 如何设计前端来处理多个后端版本

问题描述

在我的公司，我们使用 Spring Boot 来实现后端 API 和 React 来实现前端，包括 Web 界面和 Android/iOS 应用程序。

由于我们的产品是企业软件，客户实际上必须付费才能获得最新的后端 API 以部署在自己的服务器上。但是，我们的移动应用程序会定期在 App Store 上更新。这导致最终用户设备上的移动应用程序可能是较新的版本，而客户机器上的后端 API 是较旧的版本。我们计划向后支持多达 3 个次要版本，这意味着 FE 5.4 将支持多达后端 5.2。

后端确实有一个端点来返回当前版本号。但是，当我们添加新功能并可能在后端 API 中引入重大更改时，我对我们的前端实现如何保持与旧 API 版本的向后兼容性有点无能为力。

我完全理解这个问题可能没有任何漂亮的解决方案。我希望如果你经历过这种痛苦，你可以分享你的经验，你尝试了什么，你采取的最终方法以及需要注意的潜在陷阱。

我相信我自己和遇到这个问题的其他人会非常感激:)。

标签： springreact-nativeversioningbackwards-compatibility

解决方案

您的解决方案将类似于任何使用功能切换的前端解决方案，但我已经可以想象它不会很漂亮。

基本上，在您的代码中，您将有很多if/else语句或某种形式的包装器，它们在下面对每个 UI/逻辑/功能执行相同的操作，这是版本升级的重大更改。

我建议对于您拥有的每一层（UI、逻辑、API 调用），您应该开始根据后端返回的版本进行切换。你最终会得到很多看起来冗余的代码和很多看起来像这样的代码。（如果您只支持两个版本。switch如果您有更多版本，请使用）

render() {
    {version === "1.0.0" ? <VersionA /> : <VersionB/>}
}

但是，您可以编写一个实用方法，根据版本包装并返回不同的组件。通过这样做，您可以更轻松地删除将来不再需要支持的组件。

const versionSwitcher = (version, ...Components) => {
   switch (version) {
      case "1.0.0":
          return Components[0];

      case "1.1.0":
          return Components[1];
   }
}

当然，这会增加所有层的复杂性，但考虑到您的情况，我认为它并不简单。一件好事是尽量保留自己的viewModel，并且永远不要将来自 API 的响应直接传递到组件中。这减少了 API 和您的组件之间的耦合，并使这变得更容易一些。

推荐阅读