感觉是雷声大，雨点小，所以调查一下，使用egg.js的有多少？
回复
| 公司名 | 项目大小 | 类型 |
|---|
@hi363138911 离题了，可以看看 https://eggjs.org/zh-cn/intro/egg-and-koa.html#middleware ，里面有 2 个插件分别用 express 和 koa 的代码对比
创业公司，之前用的meteor，被DDP 拖的太严重，新的项目在egg和koa中选择了前者， 包括 后台和antd一起用， 然后是app后端。 然后一些基础功能 交给java
@sunfeng90 我司一个后台管理，一个微信公众号，多个小程序都基于 Meteor ，4个人全栈 Meteor。 要说方便确实在入门以后开发效率会有大幅度提升，在遇到个别问题就不如 Express 好了，比方说微信小程序的验证，支付什么的。 Meteor 确实比较重，但是 Meteor 配置环境很快，基本在编写上取消了异步回调的概念，不会有嵌套。 Meteor 也支持 Restful API。 另外在前端模版上， template 可以模块分离，实时动态更新界面，确实也挺好用的。 前后端分离，但是调 API 如调本地方法一样简单。 Meteor 主要特性是实时性，谁让它是长链接。
缺点就是： 相关错误，google 都不好搜，中文的更别说了。 太重，内部封装太多东西，概念性东西多，以至于我当黑魔法在用。 不太适应国内环境，不过也还好。
入坑Egg，收益良多。Egg充分利用并释放了Javascript语言本身的灵活性和可扩展性。在Egg基础上封装了一个上层全栈框架EggBorn.js https://github.com/zhennann/egg-born
从最开始接触到egg，慢慢的了解，权衡利弊后，所有项目也进行了改造，把之前express的代码迁移到egg。 之前的egg在vscode的调试不是很好，因为egg启动时是多个slaver的，好像是通过agent监听其中一个，后来好像优化后，vscode的调试轻松多了。 说下切换的体验吧，因为我所有项目是基于docker的，当时做了下简单的性能测试： 内存占用： * express保持在100多m左右 * egg启动后，必然到200以上 cpu占用： * express的docker环境为4%（单核） * egg的docker环境为6%（单核） 基本上，其实这些区别在java上来讲，约等于0~
总的来说，egg还是挺好的一个框架，也如上面某个仁兄所说，我也是觉得egg的代码不够优雅的，比如：
'use strict';
module.exports = app => {//这里
class ServiceBase extends app.Service { //这里
}
return ServiceBase;//这里
};
个人鄙见，狼叔莫怪，我之前尝试借鉴egg的很多方式来对express改造，但发现并工作量太大了，中途放弃了~
@mumudev 你可以这么写的：
const Service = require('egg').Service;
class NewsService extends Service {
async echo() {}
};
module.exports = NewsService;
调试那块，如果你是用第一次优化的，用插件那种方式的话，那可以再看看文档，现在已经进一步优化，直接内置到 egg-bin debug 了。
@mumudev 其实一直都是支持的，只是之前文档没写出来，当时是为了上层框架继承的考虑，后面把这个职责交给框架开发者来考虑了，所以对于应用开发者就可以建议直接这么用了，文档也都改为这个了。
旧的那种方式其实也可以很好看的… 我早期是这么写的：
module.exports = app => (
class ServiceBase extends app.Service {
}
);
现在是推荐新的模式了，毕竟 TS 什么的，都要求静态 export 。
@atian25 因为我的框架一直都是弱化api的数据计算的，采用DAAS（数据即服务）的模式。然后，我大部分service层都是可复用的，我就这么做了
// src/app/extend/service.js
'use strict';
module.exports = app => {
class ServiceBase extends app.Service {
constructor(...args) {
super(...args);
}
setModel(modelName) {
this.modelObj = modelName;
}
get model() {
if (typeof (this.modelObj) === 'object') {
return this.ctx.model[this.modelObj[0]][this.modelObj[1]];
} else {
return this.ctx.model[this.modelObj];
}
}
async getAll(query = {}, selected) {
const models = await this.model.find(query, selected);
return models;
}
async getById(id, selected) {
const model = await this.model.findById(id, selected);
return model;
}
async updateById(id, body) {
delete body._id;
const model = await this.model.findByIdAndUpdate(id, body, { new: true });
return model;
}
async deleteById(id) {
const model = await this.model.findByIdAndRemove(id);
return model;
}
async create(body) {
const model = await this.model.create(body);
return model;
}
async createOnce(body) {
let model = await this.model.findOne(body);
if (!model) {
model = await this.model.create(body);
}
return model;
}
}
return ServiceBase;
};
'use strict';
const ServiceExtend = require('../extend/service');
module.exports = app => {
const ServiceBase = ServiceExtend(app);
class Service extends ServiceBase {
constructor(...args) {
super(...args);
this.setModel('User');
}
async login({ username, password }) {
const model = await this.model.findOne({ username, password },
{ username: 1, head_image_url: 1, motto: 1, status: 1, phone: 1 });
return model;
}
}
return Service;
};
@atian25 嗯嗯，我现在的调试就是用egg-bin debug，我是说之前的时候，那个时候好像还是监听worker，因为egg支持根据核心开多线程，但这也导致不好监听，还容易监听崩溃。现在用心的egg-bin debug挺好的
@atian25 不行呀，在app.js里面覆盖，我测试过了，egg是先渲染了service层后，再给app.js调用的，估计是为了在app.js里面能够用到app.service的完整功能吧。 而且我当时为啥放到extend，也是因为我的想法就是service也应该有个可覆盖的基类才行，比如工具类这些常用的也是应该在extend/service添加的，如果egg能够支持extend/service这种方式就好了，而且支持这种应该是蛮简单的，我也可以提PR，不过也要大家觉得有必要吧
@atian25 狼叔，我换了个思路，在extend/application.js里面构建一个新的ServiceBase，然后成功了
'use strict';
// app/extend/application.js
module.exports = {
get BaseService() {
class ServiceBase extends this.Service {
}
return ServiceBase;
}
};
不过我还是觉得，应该有个extend/service.js ;)
@mumudev app.js 是可以的，Controller 和 Service 都支持修改基类的，前者在文档有写。
这块有问题我们可以提 issue 沟通，在这个贴里面讨论具体技术问题可能不是很适当。
PS：我不是狼叔。
