问题描述
我们有一台相当大的Loopback 3服务器，该服务器现已到2020年底终止使用。
我知道有关尽快迁移到Loopback 4的建议，但是犹豫进行迁移-LB4尚不存在很多LB3功能，LB4模型关系只是LB3的子集，而仅仅是纯粹的工作量。我也知道（并且已经测试过）将LB3应用程序嵌入到LB4应用程序中。
因此实际上-在可预见的将来留在LB3上有哪些实际缺点？我知道我会在以后的补丁和修复程序中迷失方向，例如安全更新，我想LB3的nodejs版本将被限制（v10？）。但是，举例来说，npm模块将变得不可用，还是服务器有一天会“停止启动”？还有什么要考虑的？
（如果闻到管理压力的话-您是对的）
解决方法
缺点
有两个主要缺点：
缺乏社区支持
由于LoopBack 3已被核心维护者终止使用（EoL），因此社区的利益也会发生变化。社区的某些部分可以选择使用其他替代方法，而其他人则可以迁移LoopBack 4。
文档或存储库都没有，但是如果您遇到某个特定问题，可能会无法获得社区帮助。
LoopBack 4将随着时间的推移不断改进，并且迁移指南将与之同时进行。因此，准备就绪后，您将有相同的机会迁移到LoopBack 4。
安全性
将不应用任何安全补丁，包括上游依赖项的补丁。由于LoopBack 3将不再从半自动依赖项更新中受益，因此难以确保软件安全性。
如果上游依赖性安全补丁很重要（应该如此），则建议维护这些软件包的分支。
流程看起来像这样：
- 将其分叉到另一个GitHub存储库
- 使用诸如Dependabot之类的自动更新工具
- 将LoopBack 3依赖项更改为重新发布的变体
Node.js安全修复程序也可能很重要。因此，应尽可能对软件包的最新LTS版本的Node.js进行测试。
维护包括更新依赖关系并修复由这些更新引起的任何不兼容性。
软件包将停止工作吗？
大多数可能不是。没有理由为什么软件包会“破坏”，排除所有未解决的错误。
作为保证，除非在极端情况下，否则NPM不允许取消发布软件包，并且package-lock.json和npm ci将确保可重复安装。
但是包锁定仅适用于直接依赖项。因此，如果任何上游依赖项应用了向后不兼容的更改，而没有一个专业大写字母，则程序包可能会无意间中断。
这可以通过使用NPM Shrinkwraps减轻，该快照将对整个依赖关系树进行快照。
Node.js版本的上限是否为10.x？
是的。这不是一个硬性要求，但是不建议您承担隐藏重大更改的风险。
LoopBack 3是一个应用广泛的应用程序（就测试而言）。因此，该测试套件可用于衡量和检测跨Node.js更新的任何潜在不兼容性。
那管理呢？
如果您能够维护LoopBack 3软件包的分支，运行测试套件并通过CI / CD管道更新依赖项和Node.js LTS版本，那么它应该是相当安全的。
LoopBack 3是一个相当成熟的项目。因此，可以假设发现了大多数关键缺陷。维护LTS期间旨在允许检测此类错误，而无需添加任何可能导致回归或新的严重缺陷的新功能。 尽管如此，仍然可能在EOL之后检测到新的严重缺陷。
您必须权衡利弊。考虑到所有这些因素，它的安全性非常依赖于LoopBack 3上运行的服务类型，业务需求以及您愿意承担多少风险。
安全软件开发生命周期非常重要，在构建产品和服务时应牢记这一点，以防止或减轻这些问题。
何时迁移到LoopBack 4
我现在开始计划迁移。由于LoopBack 4是完全重写为元框架，以适应TypeScript和OOP在Node.js中的流行，因此迁移将需要一些努力。
如果LoopBack 4中需要某些功能，则?相关的GitHub问题。 LoopBack 4是一个社区驱动的开源项目。维护者将努力满足社区的需求，而建设性的反馈意见将使核心维护者和社区维护者能够相应地确定优先级。