我正在领导产品开发并在过去一年中使用Loopback v3。它是我们使用LB v3完成的中等大小的实现。
[拥有超过一年的经验，我的结论是Loopback是一项出色而有前途的技术。但是，它有几个问题，并且没有得到应有的广泛采用。
几周前我开始分析LB4，得出的结论是LB4太复杂了，无法解决基本的全栈应用程序开发要求。尽管我同意微服务API网关需要一个良好的框架，但在我看来LB4的过程变得复杂了，我担心使用Loopback3的人们将完全放弃Loopback。
我真诚地相信-坚持使用LB3 Strongloop可以实施新技术，而无需对LB3进行重大更改-改善和强化LB3的经验，从而在引入突破性的框架变更之前增加越来越多的采用者，并使社区变得更强大。
人们对上面的想法有所了解。
温馨的问候严厉
在我的系统中，我正在使用Loopback 3运行4个微服务。我试图将Loopback 4用于我们正在开发的新微服务。我尝试使用它，但我放弃了。
我认为，Loopback 3的最大优势在于简单性。如果我需要一些复杂性，可以自己考虑。环回4尝试使复杂度e产生更大的复杂度。
我需要更改它在存储库中注入数据源的方式，以便在数据库外部使用单元测试。从那时起，我无法使用CLI，不知道为什么。没问题，我可以自己编辑文件。当我尝试这样做时，我注意到在环回3中制作简单的事情很复杂。在存储库级别建立关系是乏味的。控制器上的装饰制作样板代码，十行或更多行仅用于定义元数据。
我认为，Loopback 4开发人员将Java的一些想法带到了该框架的新版本中。输入一切都不好。我为模型使用类型。我已经创建了带有接口的类型的npm存储库。我可以在其他微服务和应用程序中使用该存储库，所有模型和API端点的类型都已标准化。
我回到环回3，这是一个很棒的框架，简单，高效且可扩展。我认为环回4带来了很多复杂性。我不喜欢。