loopback为什么火不起来?

LoopBack作为一个相对完整的API解决方案,拥有一系列的免费服务产品可用,而且本身这个框架的维护团队也大多是社区的活跃人员,甚至Node.js团队成员,应该是相对于其他,表现得更为成熟的框架之一,但是为什么现在还是动不动就express或者koa,难道每回做脚手架不累吗?
关注者
113
被浏览
12286

12 个回答

去年正好有个项目用了loopback,在一次项目的尝试后,我的建议是:
坑多误入
至于它为什么没有火不起来,我觉得有两个方面:

1、定位问题

loopback是三个 功能的集合
Express + ORM + RESTFul API
  • 基于Express 的web架构
  • 提供一套ORM解决方案
  • 结合Express提供便捷的RESTFul接入
从上面第二个功能点,可以看出,它的定位在于 提供一个完整的后端解决方案,类似于.net中的MVC+EF
而nodejs目前主流的应用场景在于中间层:通过node进行模版渲染,处理部分业务逻辑。真正的后端, 还是有专业的后端开发人员进行。

2、一些使用上的 槽点

去年公司的项目是一个纯node的项目,没有后端支撑,我们自己捣鼓mysql,memcached,redis,本来已经很痛苦,而loopback让我更痛。
  • 首先说说Express,作为web框架没什么问题,容易上手。但是作为一个完整解决方案,应该再进一步考虑web功能性的东西,比如说:日志,安全,多进程通信等等。而这些通通都需要自己捣鼓,我们得引入log4js记录日志,引入pm进行进程守护,引入graceful进行异常重启,叫运维团队来做漏洞扫描,结果还扫出不少漏洞!
  • RESTFul API,这个槽点也太多了,在这个项目中,一开始看中RESTFul API的能力,使用过程中发现,其实很不方便,loopback为每个表model自动生成了一个 API,支持put,post,get等http方法,用户可以对它进行扩展。问题在于,很多业务需要关联多表,这时候就很纠结了,这个api应该扩展到A model里,还是B 呢?后面决定直接废弃API,直接使用express的路由。
  • ORM 这块的槽点也太多,我们没有采用官方文档的model first形式,而是先建表,再生成model,表直接没有通过loopback的语法做代码级的逻辑关联。我们通过抓取mysql包发现,当做关联查询时,尼玛loopback把关联查询拆成单独的查询,再到内存里拼出最后的结果。
实际开发中,还有不少的坑,比如 关联查询这块就有不少问题。

目前团队已经不再使用loopback。转而投向了koa的怀抱,公司内部基于koa进行了良好的扩展, 为我们建立了一个功能完善的web基础框架。

顺便安利我们正在使用的sequelize(Sequelize | The Node.js / io.js ORM for PostgreSQL, MySQL, SQLite and MSSQL框架,纯粹的ORM,坑少建议有数据库操作需求的朋友可用。
我就是那种今天以前没听说过loopback的码农。跑去官网瞄了一下发表以下意见(loopback不容易火起来的原因)

1. 思想并不先进,github上面随便搜一搜用php laravel实现的CRUD脚手架满地都是,包括我都做了一个(不在github,项目已经上线用了好久了),实际上就是做个模板提前写好CRUD,然后根据用户选择替换关键字而已,各种字符串处理跟替换一点难度都没有。

我做的那个脚手架没那么神,但是通过一行命令生成Model + controller + 基本的phpunit测试用例 + 配置路由规则是都搞好了,所有涉及查询的地方(查询+编辑和删除时候的筛选条件)都支持复合条件查询还可以联表排序分页另外还顺道做好了缓存,其实也没啥难度。(PS:我入互联网坑也就三年多点,之前一直是ppt码农兼任 vb + vb.net 码农,我都能想到的东西我不觉得它有多高深)

2. 这种东西适合少数人单干不适合稍微大一点的团队,毕竟这种从数据库到MVC到前端应用通通搞定的东西需要一个统一的思想,能思考得这么透彻的码农多半也够半拉主程或架构师了,哪个团队有那么多主程高程架构师一起撸代码的。

3. 规则生硬效率低/ 学习曲线陡峭,搞了三天弄清楚用法语法规则和潜在的坑了,五秒钟调用一下以后还是得要老老实实去码业务代码,下次需要调用的时候又没那么容易想起来,又要搞一两天学会,这时候说不定人家版本更新了“引入了新特性”,又只能从头开始。

专用工具是好东西但是指望普通人掌握一周用不了一次的专业工具是不现实的。一个普通ERP三五百个表已经不少了,按一个团队10个人算(考虑上离职入职的变动至少按15人算),每人也就那个一二十次用这东西的机会,培训成本太高了。要是换个二三十个表的小系统,肯定有些人压根就没机会用。

4. 正经大项目不能指望它自动生成的东西。几千几万条数据用脚手架生成的CRUD也就罢了,真有几百万几千万或者更多数据的时候省下的编码时间估计已经不够去处理性能瓶颈负载和压力的问题了

5. 自由度太低。 loopback支持0auth鉴权,但是如果我想要用jwt的token鉴权怎么搞?我想在自定义的登录界面加个验证码怎么搞?或者我要做的查询真的复杂到它的语法不支持怎么搞?

所以推广这种技术的感觉就像是在推广一个神奇炒菜机,你只要坐在那儿按个按钮就有好吃好喝的喂到嘴里最后还帮你洗碗,但是前提条件是你得要按照炒菜机要求的坐姿,在指定时间张嘴闭嘴咀嚼吞咽。

这种为了解决一些问题而创造了更多问题的方案,不“优雅” (╯‵□′)╯︵┻━┻

=====================================
所以最佳方案还是 php或者python/ java 做API,nodejs做中间层提供路由转发到api和提供其他通用服务(文件上传下载,用户身份鉴权,session持久化,验证码,静态资源),然后angularjs做前端业务逻辑。