Comparison of the use of express and koa

Express and koa are both server-side development frameworks. The focus of server-side development is the encapsulation and processing of the two objects HTTP Request and HTTP Response, application life cycle maintenance and view processing.

When it comes to Node.js development, we have to mention the two popular frameworks express and koa. Express has been around for a long time. It is a simple and flexible web development framework that is easy to use and powerful. Koa is relatively younger. It is an agile development framework re-developed by the original team of Express framework based on the new features of ES6. It is now very popular and has great potential to catch up with Express.

Express is mainly based on the Connect middleware framework, which is rich in functions and easy to use. The framework itself encapsulates a large number of convenient functions, such as routing, view processing, etc. Koa is mainly based on the co middleware framework. The framework itself does not integrate many functions. Most functions require users to require middleware to solve them. However, due to its middleware mechanism based on the ES6 generator feature, it solves the long-criticized "callback hell" ” and troublesome error handling issues are very popular among developers.

I actually wrote a comparison between express and koa before, but later I found that there were many fallacies in it. So I have been thinking about correcting the previous mistakes, especially the comparison of the middleware part.

The express here is replaced by a simpler connect

Connect execution process
Usually we say that the middleware model of connect is linear, that is, it is executed one by one, as shown below:

Of course it is correct to say this, but when we execute the following code, we may have a little confusion:

const connect = require('connect')
const app = connect()
app.use(function m1 (req, res, next) {
 console.log('m1')
 next()
 console.log('m1 end')
})
app.use(function m2 (req, res, next) {
 console.log('m2')
 next()
 console.log('m2 end')
})
app.use(function m3 (req, res, next) {
 console.log('m3')
 res.end('hello')
})
app.listen(8080)

When we access When http://127.0.0.1:8080, the console will print the following:

m1
m2
m3
m2 end
m1 end

This result seems to be a little different from the model above. Isn’t it linear? Why does the code after next still appear? Continue to execute? Of course, we have already concluded this before. If you are interested, you can take a look in detail. We will take the results directly now. The pseudo code of the middleware model of connect is as follows:

http.createServer(function (req, res) {
 m1 (req, res) {
 m2 (req, res) {
 m3 (req, res) {}
 }
 }
})

You can see that Nested callbacks layer by layer, let’s simplify the code we had some doubts about before:

http.createServer(function (req, res) {
 console.log('m1')
 m1 (req, res) {
 console.log('m2')
 m2 (req, res) {
 m3 (req, res) {
 console.log('m3')
 res.end('hello')
 }
 }
 console.log('m2 end')
 }
 console.log('m1 end')
})

Don’t be confused by the above callbacks, it is a very simple callback function, everything is explained Done: Even after res.end, our code still has to continue going down. It can be said that the middleware of connect is actually onion-shaped, but because it is a synchronous code, it is generally not done like this, so we can do the above Let’s describe the middleware model of connect again:

Koa’s execution process

Similarly, when we analyze the Koa source code, we also talked about Koa Middleware model: Onion-shaped

## Take the following code as an example:

const Koa = require('koa')
const app = new Koa()
app.use(async function m1 (ctx, next) {
 console.log('m1')
 await next()
 console.log('m1 end')
})
app.use(async function m2 (ctx, next) {
 console.log('m2')
 await next()
 console.log('m2 end')
})
app.use(async function m3 (ctx) {
 console.log('m3')
 ctx.body = 'hello'
})
app.listen(8080)

Access the service, output:

m1
m2
m3
m2 end
m1 end

emm seems to be no different from connect. I have read an article before, and after experimenting here, I came to the conclusion that there is no difference between the middleware models of koa and express. I am also confused, of course, there is a difference. The conclusion will be discussed later. The same here Just take out the simplified model of koa middleware:

Promise.resolve(async m1 () {
 console.log(m1)
 await Promise.resolve(async m2 () {
 console.log(m2)
 await Promise.resolve(async m3 () {
 console.log(m3)
 ctx.body = 'xxx'
 })
 console.log(m2 end)
 })
 console.log(m1 end)
})

We know that the function of async/await is to 'synchronize' asynchronous operations (it seems so, but it is not, but we don't need to worry about it), so here it is Promise is naturally 'synchronized', which means that all asynchronous operations of console.log(m3 end) can be 'synchronized'.

Conclusion

Before I state the conclusion We can actually think about it. Since the middleware of connect is also in the shape of an onion, there seems to be nothing wrong with using it the same as koa. Then let me imagine that our service needs to get a user in the database, let's say it is getUser. Of course, getUser is asynchronous. Let’s take a look at the methods of connect and koa respectively:

// connect
app.use(function (req, res) {
 getUser(user => res.end(user))
})
// Koa
app.use(async (ctx) => {
 const user = await getUser()
 ctx.body = user
})

Of course, it seems that there is no difference. Then let’s just give the conclusion (hold back): connect’s middleware is synchronous, not It will 'wait' for other asynchronous operations, but koa can 'wait' for asynchronous operations. Of course, there is no problem if you don't wait.

Related recommendations:

Compare the differences and connections between express and koa middleware modes

The above is the detailed content of Comparison of the use of express and koa. For more information, please follow other related articles on the PHP Chinese website!