写在前面的话

实在抱歉是受了#极客学院#外宣部妹子委托，才将自己最近使用loopback的经验分享于此，希望在完成妹子任务之余，也能对读者有所帮助，中文社区只发了CNode社区，如果习惯英文阅读的童鞋也可以直接去我的medium阅读评论：https://medium.com/@yorkienell/trip-of-loopback-56aa4115d69d

废话不多说，正文由此开始

如题目所见，这并不是一篇旅游形记，也不是一篇关于回环地址(127.0.0.1)的科普文，也并非一篇覆盖Web框架loopback.io各个方面的一篇技术文。 此时，只想跟大家分享在最近一个月之内使用loopback的一些点滴感受。

背景

几个月之前，我分别在给纽约和亚洲的两个创业团队工作，这两个团队的工作中，我们很明确地都在使用express作为底层开发框架。纽约的项目在前端方面表现得十分不错（https://pixbi.com），因为我们只在服务器端使用了express框架，所以随着业务逻辑的变更以及增加，服务器的代码总是跟不上前端的进度，原因是为了达到团队内部要求的代码质量，我们不得不一次次地重构代码，夸张得说，如果有时超过一周不对一些老的、旧的代码进行一定的清理，整个项目就几乎就很难再进行维护与开发了。

亚洲团队在使用express的糟糕处境更加明显，虽然团队内部也有其他问题存在，事实上团队成员来自整个亚洲地区，如中国内陆，越南，日本，印度以及来自加拿大时区的设计师妹子。因此我们往往都是工作在不同地时区与不同的办公室，团队中管理也存在很多问题。

不过不得不说，仅仅基于express的基础架构设计确实是让整个团队的进度经常被延期到投资人几乎快无法忍受的地步，使用这一架构让整个团队把过多的注意力、精神力放在了怎么构建infra，而不是核心的商业逻辑。直到一个月前，我被委派成为后端新的技术负责人重新调整架构，我所做的第一件事就是使用loopback来对原来的业务进行重构，提高项目的敏捷度。

loopback vs. meteor

其实不选择使用meteor的原因非常简单，虽然meteor拥有更加完善的社区组件以及更加活跃的开发团队，不过考虑到代码的简洁程度以及团队需要的仅仅是一个API服务器，因此meteor对于彼时的我们太过重量级了。

loopback帮助了我们什么？

使用loopback最重要之原因即通过更新基于JSON的模型文件就能完成大部分的商业需求（前提是商业需求需要按照REST的风格去整理，思路清晰）。另外StrongLoop团队也内建了很多很方便使用的模型，比如UserModel, PersistentModel等，这些模型对于大部分商业需求已经变得足够易于使用了。

并且得益于loopback项目（github地址：https://github.com/strongloop/loopback）清晰明了的代码结构，开发者可以快速地通过阅读代码来了解和追踪错误或者Bug发生时，内部的情况。

在对比了使用loopback前后代码库的复杂度后，总结了如下的一些数据：

1. 代码总行数减少了70%
2. 控制器总行数减少了90%
3. 模型实例总行数减少了10%
4. 视图代码保持不变（因为基本没有）
5. 商业逻辑无关代码减少了99%

提升是明显的，特别是第五项的提升，这也是为何我如此强烈建议你应当直接在商业项目中使用loopback的原因，这个原因也相当地明确，即我曾经经历过太多的项目在技术上的失败是因为过多的关注一些与商业逻辑无关的事情了。

仍然有被loopback困扰之处

是的，如你所见，loopback的社区并不发达（毕竟是以公司进行驱动），可以从其在Github的项目上，堆积如山的Issues与PRs就能看出，开发团队的反馈并不够及时。这些显然是比不过express, koajs以及meteor的。

但这里需要再次感谢于loopback清晰的代码结构，即使社区反馈不够快，大家也仍然可以快速、简单地通过阅读文档，或者直接阅读代码了解其内部的处理机制，来追踪你所遇到的问题。请相信我，对于大多数nodejs开发者来说，以上阅读文档以及源代码的过程并没有那么困难，因为我一直以来就是如此在调试我所有在使用loopback的项目的。

结尾

写下此文的目的绝非我是一名来自StrongLoop公司的员工，唯一以及最初的目的只是想通过我的使用经历让广大开发者可以以一种最简单的方式给自己的用户，或同事，或Boss交付一个健壮可靠的Nodejs应用。