Nodejs 后端使用 express 还是 koa?

发布于 1周前 作者 vueper 来自 nodejs/Nestjs

Nodejs 后端使用 express 还是 koa?

想把个人网站的后端换成 Node,但是对两个框架犹豫不决,哪个综合来看好点呢?或者企业用的比较多的是哪个?

71 回复

这个问题就相当于你去买电脑,问是买带外设的套装电脑好还是不带外设的独立主机好。

express 跟 koa 在性能上并没有什么区别,只是在软件工程上面有着它们的设计倾向。
一个是大而全,省事。一个是小而精,定制化容易。

对于个人网站来说,两个都一样。

会哪个用哪个;
如果都不会,随便挑一个;
如果都会,你应该自己可以决定。

nestjs 吧,基于 express,

喜欢 Typescript 和类 java 的依赖注入的话 试试 midwayjs

这二个哪个是大而全?

忘了在哪看到这句话了: express 全 fastify 快 nest.js 稳

我觉得 fastify 蛮好用的

曾经用 koa,现在直接 express,直接用现成的也没什么问题

用过 express 还行。我反正是抄 real-world 的。node 后端它只有这么一种实现。

看了大家的回复更想哭了。。。

以前用 koa.觉得精简.后来出了 koa-router 时间.发现生态真心不能等.重新回到 express.发现都那样.如果喜欢 ts 都可以直接上 nest.js

nest 可以看看

个人网站啊,那随意

http 和 net 选一个

随便都一回事,要我建议别用 node

个人网站干什么的,静态 blog 系统满足不了吗?

喜欢注入风格不妨看看我整理的这个 Guide: https://github.com/WittBulter/koa2-typescript-guide

就你说的这两个的话用 express,node 早就支持 promise 了,其他跟 koa 没啥区别,就多几个内置中间件

我记得我还上学的时候, 学 node, 当时就有这俩框架了, 然后当时的教程说 koa 是新的, 要替代 express … 看起来过了几年这事没实现啊

nest 实在太优雅了,强烈推荐。

fastify,或者 nest+fastify

Fastify 现在号称是最快的 nodejs 框架

写了 3 年的 nodejs
我推荐还是 koa 大系统用 Fastify.
别学 ts 语法

写无状态服务用 koa 以后都是云函数服务
然后写代码别 mvc 架构.多用 api Gateway 写法.也利于分部署部署
别加载太多各种依赖…一个简单的 http 服务不需要那么多东西…
处理好异常.数据库连接.那些就基本够了.

如果这些都懂了…学门其它语言吧
nodejs 不适合高并发业务.做做后台管理系统 api 还可以.不过普通小企业还是很适合的.创业公司.有钱和谐微服务转 go

果断 fastify,带验证可以避免很多错误

https://2018.stateofjs.com/back-end-frameworks/overview/
为啥没人推荐 nextjs(不是 nestjs),谁能解解惑吗

越看越不靠谱。还有让转 Go 的

node 不就是做高并发的么,怎么到你这儿就不适合了

nextjs 不是前端框架吗?基于 react 的

#37
#5
老铁,你们一个 react 一个 vue 的 ssr 框架,是认真的吗?

写过 eggjs 之后,感觉还是 nest 比较适合我

看了大家的回复,有点想试试 nest 了,但是看了一眼,优先 ts,感觉有点难以接受。我是不打算写 ts,不然当初也没必要从 java 转过来 node。有用 nest 不用 ts 的吗?

没人推荐 sails 么

长期维护的项目还是推荐基于 ts 的比如 nest,短期一次性项目 koa 吧。express 的中间件不是洋葱圈有点难受。

看了下,感觉不灵活啊,还是 nestjs 好点

这种问题最好的解法就是:都用一遍,哪个顺手用哪个。

当然,我个人推荐 Egg.js ,什么依赖注入啊,不太感冒,没法儿,谁让我是 Java 黑呢

例如订单和数据库相关的事务方面的.nodejs 不适合做业务核心高并发的…做做分发前端渲染那些还可以.

我也是 java 转 nodejs 也有 3 年了…nodejs 优势是比 java 强太多了…这样说可能很多人不爽我…不过我外包或者普通 crud 基本也是 nodejs 写的了…包括小游戏…普通接口压力.nodejs 还是很个给力的…一个没经验的 java 写的并发或者普通企业写的接口可能差过我 nodejs…现在 nodejs 对于大数据处理还是瓶颈很大…我 nodejs 原生+es6 我觉得非常完美的方案了…高并发核心模块用 rpc 转 go 来写…
go 也是下一个趋势了.省内存.快捷…java 就算了.都是吹 ppt 的.我见多了.实际业务代码能力差的很…我对国人写 java 很伤心了.

#51 握爪,我也是差不多 15 年转 node 的,现在公司项目全线 node。模块化拆分,独立发布我觉得都很方便了。

go 目前还用不上,以后再说。

我觉得确实是存在一批能力很差的生存在底层的程序员,业务代码能力非常差。

不过 java 也有点优势。比如我们最近项目 mq 选型选了 rocketmq,买了阿里的服务,结果只有 java 的客户端比较完善,node 的客户端一塌糊涂,并且没有进展,绝望.jpg

express 稳一点吧,那些口口声声要代替 express 的至今感觉都有气无力了。

看样子没人用 hapi。。
我公司项目都是 eggjs。基于 koa 封装的,比较容易上手。
个人的话,我觉得随便哪个都行吧,看哪个 logo 好看就用哪个哈哈哈。

印象里《 Node 实战》里有基础框架的横向对比,讲选型策略的时候给了些建议都挺实用

消息队列的还好…有 http 协议就自己封装一个 sdk 单例使用…我觉得就够了…如果不是特别多业务的.可以自己 redis 写.

麻烦的是走 socket 协议的一些 rpc 断连就会出事.又或者重复发送.

egg 是 kpi 的产物…看看他们的代码就好…
自己用就还是自己搭建一个就够了.其实写个接口服务.不需要那么多东西的…

hapi 就非常垃圾了.整一个 mvc 的做法.弄一套自己的标准…背离了用 nodejs 特性的初衷…
写无服务的模块化才是未来的发展.哪个不爽重写就好.不用担心其它代码依赖

#57 选 rocketmq 的原因主要是因为有延迟消息的功能。我们的业务场景里有很多需要一定时间后触发的。不想搞任务系统,我就想用 mq 来实现。

#54 koa 和 express 貌似 log 都是需要自己加载中间件的

只用过 express

所以我选择了 eggjs,封装好了很多,还能接入阿里云的 node 监控方便啦

哈哈,所以 hapi 我就用于自己测试瞎折腾,我是个好奇心重的人,一有啥新东西就想试试看看有没有什么惊奇的发现~~~
用于生产环境我一般都是 eggjs,之前自己用 koa2 从 0 手工一步步搭起来,项目跑通了各种毛病,然后领导说你咋不用 eggjs,我就重构成 eggjs 了,因为,我开发时间也是比较紧张的。nodejs 开发经验不足的情况下在工作中也不敢瞎折腾了= =!

其实 eggjs 也没很多东西.基本封装个 class 都全了…不过要看自己经验了… 阿里云 node 监控还是少用…性能比较低…它改了 nodejs 的底层…而且版本升级太慢…如果你要集群部署…用原生的好+es6 不要加其它编译了.
nodejs 新版本启动基本也就 50m.压测后.gc 后也稳定 100m 的状态

如果是新手 建议 Koa2,如果不是新手,建议 Nest

推荐用 egg 吧

koa 不是刀耕火种自己搞。。。我觉得还是用 Nestjs 省心。。。

前辈有推荐的技术栈(技术架构)吗?

个人网站还是 hugo 省心。。

在选择Node.js后端框架时,Express和Koa都是热门选项,各有千秋。以下是对两者的详细对比:

Express

  • 特点:设计哲学是“约定优于配置”,提供丰富的中间件生态系统,上手容易,是Node.js开发者的首选框架之一。
  • 代码示例
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello World!');
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

Koa

  • 特点:设计哲学是“中间件优先”,更加轻量和富有表现力,鼓励使用现代的异步函数,使得代码更加简洁易读。
  • 代码示例
const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = 'Hello World!';
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

总结

  • 如果需要快速上手、社区支持丰富且文档齐全,Express是不错的选择。
  • 如果追求代码简洁性、现代异步编程实践和更高的灵活性,Koa可能更适合。

总之,选择哪个框架取决于项目的具体需求、团队的技术栈以及开发者的个人偏好。

回到顶部