Egg框架能不能火起来
发布于 7 年前 作者 yilikun 19802 次浏览 来自 问答

求大神分析一波~~

egg

70 回复

@aylizhiyuan 求大神分析

@aylizhiyuan 快来啊~~~~~~~~~~~~~

哪个用的习惯就用哪个就好嘛,一个框架除了代码质量、架构设计,还有文档、推广、科普等,不是一句二句说的清的

老实说,火不火其实关系不大,没必要太纠结。

搬运下之前在 https://github.com/atian25/blog/issues/18#issuecomment-289940960 的回复吧:

@cncoder 这么说吧,作为一个学生,能这么早关注业界的东西,挺不错的了。

但有几点建议:

估计egg再火,BAT中的BT也不会用

  • 怎么样的才叫 BAT 都在用呢?光阿里内部,几千号前端,百来个小组,是不是 100% 都在用,才叫用呢?你怎么知道 BT 中没有团队在用呢?
  • 退一步,Koa 算不算 BAT 都在用呢?Koa 比较底层,一般团队都会需要在上面做一层包装,如果回头你进的团队是这样的,你会不会告诉你老大:「我估计我们这个框架,也就我们团队在用,公司级别都推不动,更别提 BAT 了,所以我拒绝使用」?甚至如果你的团队还在用 express 呢?

只怕学完变成以后工作的“周末玩具”

  • 作为学生或者说初学者,建议像海绵那样,多去学习,多去吸收,不要太功利化。
  • 学习 Egg.js 不代表你必须用它,它也不会成为你学习后,一生都会用的东西。
  • 而是要去思考,Egg.js 遇到了什么问题,解决了什么问题?同类框架是如何解决这个问题的?他们之间的对比是怎么样的?谁优谁劣?如果他们的方案各自优点结合起来,又会怎么样?
  • 不要人云亦云 KPI,那是别人黑着玩的,跟你有什么关系么?看看文档,看看源码,能有收获就值了,如果发现写的很烂的话,直接跳坑咯。没有一个框架是你学习后可以用一辈子的,程序猿最怕的是「你那不叫十年工作经验,是一年工作经验用十年。」

方便以后造轮子

  • 在文中其实提过 「其实大家的基础框架用不用 egg 真的无所谓,最重要是有一套适合团队的约定。」
  • 或者这么说,未来你参与面试的时候,面试官希望听到你说 「我用过 xx 框架」,还是希望听到你说:「我在做 XX 项目的时候,预研过 XX 和 YY 框架,最终因为 XX 等原因,我选择了 XX 框架。在这过程中,我遇到了 XX 问题,为此我去看了 XX 源码,发现他们是基于 XX 原理的,还有优化的空间,于是自己尝试了 XX,解决后写了 XX 总结文章,甚至尝试给 XX 框架提了一个 PR 解决了这个问题」

@i5ting 谢狼叔科普

@atian25 谢谢回答!

@atian25 猪哥说的好实在啊

我在做XX项目的时候, 发现 XX 和 YY框架都不好, 最后我就自己去造轮子 ZZ 了, 然后项目黄了 :) 手动滑稽 😂

@aitian25 打这么多字不容易,给个赞 自豪地采用 CNodeJS ionic

@magicdawn 似乎很在理,学暴雪,做款游戏造一套引擎!

取其所長就行了,Node的風格不適合大框架,適合組合。

@arden 请问有什么依据没

已经火了~

能学到东西就好。其实看eggjs,很多东西与其他语言后端涉及上还是很相似的,通过它的用法,学习它是怎么去处理一类问题的

所以为啥不学koa和express?阿里的东西不都是那样么?

我给团队的最终选型是 egg,至于火不火我不知道,只说说我为什么选它

  1. 他是基于 koa 的,koa 是一定要选择的,只因为 async/await 。egg 是对 koa 的包装,即时你的团队是用 koa 的,但是不可避免的要自己包装一层,所以有现成的并且很优秀为什么不用?
  2. egg 的作者们都是大牛,给 node 和 koa 都贡献过代码,所以我相信他们,或者看 egg 源代码,如果你能力可以,那么你应该能看出来 egg 写的比其他一些什么框架代码质量/可维护性/可读性都高出很多
  3. 测试做的非常棒,据我所知没有几个国内开源项目有这么高的覆盖率
  4. 扩展度也很高,很多功能以插件方式提供的,所以正如 egg 官网说的一样,你可以基于 egg 搭建一套适合企业业务的基础框架出来
  5. 更适合企业团队开发使用,他有一些约束和规则
  6. 暂时想到这么多,其实还有一些原因的

顺便说说我理解的使用 egg 的正确方式

  1. 建议企业级团队使用,个人弄个小项目的话我觉得用什么都没多大区别
  2. 要根据自己企业业务在 egg 之上再包一层,最终会变成 “kao --> egg --> 你的企业框架 --> 业务代码” 这个层级关系
  3. 跟 egg 无关,企业团队项目最好用 ts,假如你希望你的项目变成“大”项目“长”项目的话

@okoala 哈哈 是的 看这个问题就知道了。。。 我也有份功劳啊

@rwing 多谢回答,学习了:thumbsup::thumbsup:

我觉得egg入门容易,并且简单易学。火不火只是时间问题。

@rwing async/await和koa没啥关系吧。。。koa2虽然开始大规模并且推荐async/await但是你express想用async/await就不能用了?

egg是一个相当庞大的封装,egg的源码里能学到很多东西。。

这问题已经火了啊

@artisan 能用是用,但是你会发现各种别扭啊,这就好像,你想用v12的发动机,那么底盘/车身/轮毂都要配套才能把发动机发挥到极致,你不能随意搭配个夏利的车身是不是?

@atian25 不能同意更多

个人觉得这种纯开发规范、插件级别的封装,对于公司可能很有用的东西,开源社区可能并不会很感冒。。远不如一个基于 ts/flow 的支持 静态类型的 框架关注度大。。比如 typeorm 之前我看才几百 star,如今已经2k+了。。也许你会说 egg更多,但是 egg 是在有大公司做推广的,typeorm 则基本是社区的产物,star 质量也不一样。。

@zaaack 是的,因为一直觉得node生态还在成长,企业级开发那块可能相对来说标准还没定,egg就是想立个标杆吧。个人理解

@yilikun 标杆立早了,用函数去返回类,这对于静态类型的支持可不太好。。😂

来自酷炫的 CNodeMD

@zaaack 指的是 module.exports = app => class Test extends app.Service {} ? 有支持 module.exports = class Test extends egg.Service {}

@atian25 哦哦,学习了。。

综上所述,大家可以看到,我们是如何一步步渐进的去进行框架演进,得益于 Egg 强大的插件机制,代码的共建,复用和下沉,竟然可以这么的无痛。 注意:不管是应用/插件/框架,都必须编写单元测试,并尽量实现 100% 覆盖率

@dayuoba 引用的嘛,哪里的

来自酷炫的 CNodeMD

@yilikun 官网文档,渐进式开发那一章

https://eggjs.org/zh-cn/tutorials/progressive.html#写在最后

综上所述,大家可以看到,我们是如何一步步渐进的去进行框架演进,得益于 Egg 强大的插件机制,代码的共建,复用和下沉,竟然可以这么的无痛。

  • 一般来说,当应用中有可能会复用到的代码时,直接放到 lib/plugin 目录去,如例子中的 egg-ua。
  • 当该插件功能稳定后,即可独立出来作为一个 node module 。
  • 如此以往,应用中相对复用性较强的代码都会逐渐独立为单独的插件。
  • 当你的应用逐渐进化到针对某类业务场景的解决方案时,将其抽象为独立的 framework 进行发布。
  • 当在新项目中抽象出的插件,下沉集成到框架后,其他项目只需要简单的重新 npm install 下就可以使用上,对整个团队的效率有极大的提升。
  • 注意:不管是应用/插件/框架,都必须编写单元测试,并尽量实现 100% 覆盖率。

@atian25 了解

来自酷炫的 CNodeMD

对我学习node有点点帮助!

@zzw64205659 只是点点帮助吗…微笑

来自酷炫的 CNodeMD

喜欢就用,管他火不火

这个话题提出来半年了,现在egg社区如何呢?

不能,从npm的生态和cb/co/yield/async/await 各种风格的写法,就知道nodejs的整个生态是倾向于多样性的,就是传说中的百花齐放,npm中很多模块,就相当于传统语言的一个api 在其他语言中很难看到一个字符串leftpad做为一个package这样的情况 所以nodejs这个大环境是傾向于发散的,而象java那样ssh封装了再封装,最后拼凑成一个类似解决方案的大一统的框架在nodejs中不会出现,因为那样就失去了nodejs灵活性,而且从另一个层面带来了调试和侦错的复杂性

火不火其实关系不大, 就是习惯问题. 比如国内的 egg, thinkjs 等. 基于 koa 去实现的, 所以呢我也自己基于 koa 写了一个框架吧, 用typescript 开发, 并已上线了自己的网站 http://fm126.xyz/ 感觉也挺好的.

开发者当然希望自己使用的框架越火越好 这样框架才能不断更新维护。

赌博式学习方法

12年最火的技术是啥? 现在埋在什么地方?

不管能不能火,反正我觉得对我们公司来说是一个很值得尝试对技术。需要nodejs,把java的业务逻辑放到nodejs来做,以此解放后端。而egg我最看重的就是他的规范订的特好,一般开发人员只需要填代业务逻辑代码就好,这样就抹去了一些能力上的差距

我认为, 无论什么语言, 应该像javaEE那样的设计才正确 所以, 我自己用nodejs去模仿javaEE的设计, 底层用koa

解决问题还是根本

@151263 那nest.js适合你

我们的新项目用的就是EGG,看上的是它的规范

@Daniel1989 是的,但是建议配合ts使用,味道更佳~

@dengnan123 猛德 一笔啊楠哥

@dengnan123 赶紧出个教程耍一耍

@yilikun @dengnan123 可以看下 「当 Egg 遇到 TypeScript,收获茶叶蛋一枚

https://cnodejs.org/topic/5ac5ecdee34737560fccaa40

@atian25 大赞!!解决痛点的好文章!

@atian25 貌似只有使用ts才能在vscode里用cmd跳转到对应的方法?

@yilikun egg-ts-helper 那个修改下,应该也能部分解决 js 版的

额。。 突然发现这个贴已经过去一年了啊。时光如梭。

@atian25 对啊!一不小心挖了个坟,那时候还在犹豫,现在已经是这番光景。。

时光如梭么

来自酷炫的 CNodeMD

@atian25 哈哈哈 这个还真不是~小弟现在是蛋蛋的忠实拥趸,已经切身感到蛋蛋的火热了,不用提问啦

@yilikun 那就过去分享下你的使用感受吧,哈哈

@atian25 这个可以有!先收藏,最近比较忙,闲了去喷一哈~

@151263 这个言论未免太过了吧。。发展至今每个语言都有它自己的优缺点,只能说分场景,在某个场景‘更’适合用某个语言

火不火得起来先不说,最近刚开发一个网站Awehunt就用的egg。之前用过express和koa,坦白讲,express相对陈旧,对promise等新模式支持不足,koa太简易了,几乎所有周边得一个个找或造轮子。egg刚好弥补了这两点缺憾,用起来感觉轻便,易扩展,同时官方也提了cookie/session/security等很多周边的支持。没有的自己extend/middleware一个也很快。

回到顶部