调查一下,使用egg.js的有多少?
发布于 4 个月前 作者 i5ting 2997 次浏览 来自 分享

感觉是雷声大,雨点小,所以调查一下,使用egg.js的有多少?

回复

公司名 项目大小 类型
54 回复

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

看来狼叔心动了啊

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

用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 , 小尴尬

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

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

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

只扒了其中部分代码用

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

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

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

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

不是我黑蛋,实在是坑。 我用的是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

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

@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半年了…

回到顶部