loopback为什么火不起来?

LoopBack作为一个相对完整的API解决方案,拥有一系列的免费服务产品可用,而且本身这个框架的维护团队也大多是社区的活跃人员,甚至Node.js团…
关注者
90
被浏览
6196

11 个回答

去年正好有个项目用了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,坑少建议有数据库操作需求的朋友可用。
2年前就使用过 Loopback + AngularJS 完成过 App 项目 Json API 管理后台。

现在推荐 APP 开发者使用 Django + RESTful API 方案,开发效率更高,维护难度更低,开发文档更容易获取。