哈哈 确实在用，但是公司和项目不方便透漏

看来狼叔心动了啊

下个小项目打算入坑，用蛋

用egg做了一个小项目，一上线运行了

昨天做了一个个人项目，一个小demo，用着还不错

来自酷炫的 CNodeMD

有一个问题 express 的线性和 koa 2与 egg 的洋葱类型，不了解为何要设计成洋葱这样的。

@hi363138911 离题了，可以看看 https://eggjs.org/zh-cn/intro/egg-and-koa.html#middleware ，里面有 2 个插件分别用 express 和 koa 的代码对比

创业公司，之前用的meteor，被DDP 拖的太严重，新的项目在egg和koa中选择了前者， 包括 后台和antd一起用， 然后是app后端。 然后一些基础功能 交给java

@Joursion 我司也是 meteor ， 小尴尬

@atian25 非常感谢

我已经在南蛮之地的小城市小公司里向其他程序员推egg框架了,公司名称不值一提

刚入坑

使用 egg.js 开发了两个 移动端项目的 API

已经入坑，初步感觉这框架设计，是我想要的东西，但有几个地方的设计，没达到我想要的，具体，等先把个人的小项目，做得差不多了，再评论，感谢 egg 团队

只扒了其中部分代码用

已经入坑

没在用

没有过，也不打算用，路过。。。

借鉴egg的一些理念和方法封装了我们团队自己的框架 thinkkoa

虽然没有直接用，但通读了源码，受益良多

express 自豪地采用 CNodeJS ionic

还在等待稳定和沉淀，预计下半年入坑

不是我黑蛋，实在是坑。 我用的是https://thinkjs.org/，这个比较稳，坐等发正式版本3.0

@hi363138911 meteor 重不？好用不？和LoopBack相比，有什么优势

@richenlin @chengnuo 叫 thinkxxxx 的是不是都是从 thinkphp 转的…

@sunfeng90 我司一个后台管理，一个微信公众号，多个小程序都基于 Meteor ，4个人全栈 Meteor。 要说方便确实在入门以后开发效率会有大幅度提升，在遇到个别问题就不如 Express 好了，比方说微信小程序的验证，支付什么的。 Meteor 确实比较重，但是 Meteor 配置环境很快，基本在编写上取消了异步回调的概念，不会有嵌套。 Meteor 也支持 Restful API。 另外在前端模版上， template 可以模块分离，实时动态更新界面，确实也挺好用的。 前后端分离，但是调 API 如调本地方法一样简单。 Meteor 主要特性是实时性，谁让它是长链接。

缺点就是： 相关错误，google 都不好搜，中文的更别说了。 太重，内部封装太多东西，概念性东西多，以至于我当黑魔法在用。 不太适应国内环境，不过也还好。

@hi363138911 原来 Meteor 还有人在用的啊。。

我用了在游戏后台管理系统上，两个公司使用了 From Noder

@Rwing 从thinkjs入坑

小公司，主要用于公司内部系统、搭建基础服务。扩展还是非常方便的。不过就是感觉写起来不够优雅~~

@hi363138911 嗯，谢谢分析

@looading 具体哪些不优雅？

小作坊，内部一个小后台系统，新手比较菜，到处寻找资源无果，自己龟速摸索中，求大牛们拿demo砸我啊~~~~

用在公司一个子项目的后台，小系统功能不多。 egg稳定性还是可以的，不觉得有什么坑的地方。

入坑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改造，但发现并工作量太大了，中途放弃了~

在用，很方便。用了之后，基本上没有再看其它的nodejs web框架。

@mumudev 你可以这么写的：

const Service = require('egg').Service;

class NewsService extends Service {
  async echo() {}
};

module.exports = NewsService;

调试那块，如果你是用第一次优化的，用插件那种方式的话，那可以再看看文档，现在已经进一步优化，直接内置到 egg-bin debug 了。

@atian25 咦，这样子，我去看看。最近搞前端去了😂 好像新的好看点了

来自酷炫的 CNodeMD

@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挺好的

@mumudev 你其实可以直接把 service 基类覆盖掉

@atian25 也对哦，找个时间在优化了

@mumudev 几行代码就搞定了，把 ServiceExtend 这个移到 app.js 来引入，就不用每个 Service 定义都要 require 了。

在用，已经做过一个项目了，体验挺好

@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 ;)

小牛电动，开放平台（暂未上线），egg+vue模式开发，优点是整合及扩展比较好，缺点是前期踩坑很多，文档不全。整体来看还是不错的，框架好不好看使用场景及组织能力

@DragWeb vue 这块的实践，欢迎给我们提 PR 一起优化，还有多写点踩坑分享~

啊啊啊，才发现名字叫错了><@atian25

@mumudev app.js 是可以的，Controller 和 Service 都支持修改基类的，前者在文档有写。

这块有问题我们可以提 issue 沟通，在这个贴里面讨论具体技术问题可能不是很适当。

PS：我不是狼叔。

在南蛮海岛上小公司里入坑egg半年了…

在西安入坑eggjs半年了，做了两个小项目

目前所有中间件及个人负责项目，全部用 egg From Noder

新项目正在用

thinkjs相比eggjs，更容易使用，主要是thinkjs自己有对数据库的封装，用起来方便。