Express와 Koa의 사용 비교-JS 튜토리얼-php.cn

Express와 Koa의 사용 비교

小云云

풀어 주다： 2018-01-27 09:58:25

원래의

2715명이 탐색했습니다.

Express와 koa는 모두 서버측 개발 프레임워크입니다. 서버측 개발의 초점은 HTTP 요청과 HTTP 응답이라는 두 개체의 캡슐화 및 처리, 애플리케이션 수명 주기 유지 관리 및 뷰 처리에 있습니다.

Node.js 개발에 관해서라면 두 가지 인기 있는 프레임워크인 express와 koa를 언급해야 합니다. Express는 사용하기 쉽고 강력하며 간단하고 유연한 웹 개발 프레임워크로 오랫동안 사용되어 왔습니다. Koa는 ES6의 새로운 기능을 기반으로 원래 Express 프레임워크 팀에서 재개발한 Agile 개발 프레임워크로 현재 매우 인기가 높으며 Express를 따라잡을 수 있는 큰 잠재력을 가지고 있습니다.

Express는 주로 Connect 미들웨어 프레임워크를 기반으로 하며, 이는 기능이 풍부하고 사용하기 쉽습니다. 프레임워크 자체에는 라우팅, 뷰 처리 등과 같은 많은 편리한 기능이 캡슐화되어 있습니다. Koa는 주로 공동 미들웨어 프레임워크를 기반으로 하며 프레임워크 자체에는 많은 기능이 통합되어 있지 않습니다. 대부분의 기능을 해결하려면 미들웨어가 필요하지만 ES6 생성기 기능을 기반으로 하는 미들웨어 메커니즘으로 인해 오랫동안 비판을 받아온 문제를 해결했습니다. "콜백 지옥"과 골치 아픈 오류 처리 문제는 개발자들 사이에서 매우 인기가 높습니다.

실제로는 express와 koa의 비교를 썼는데 나중에 보니 오류가 많더라구요. 그래서 이전의 실수, 특히 미들웨어 부분의 비교를 바로잡을까 고민했어요

여기의 express는 더 간단한 Connect는

connect의 실행 프로세스를 대체합니다. 일반적으로 connect의 미들웨어 모델은 선형이라고 말합니다. 즉, 아래와 같이 하나씩 실행됩니다.

물론 맞는 말이지만, 다음 코드를 실행할 때 약간의 혼란이 있을 수 있습니다.

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)

로그인 후 복사

http://127.0.0.1:8080을 방문하면 콘솔에 다음과 같이 인쇄됩니다.

m1
m2
m3
m2 end
m1 end

로그인 후 복사

이 결과는 위와 동일합니다. 모델은 다음과 같습니다. 선형적이지 않습니까? 다음 코드가 계속 실행되는 이유는 무엇입니까? 물론 이전에 이미 결론을 내렸으므로 직접 결과를 살펴보겠습니다. 이제 연결 중에 소프트웨어 모델의 의사 코드는 다음과 같이 표현됩니다.

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

로그인 후 복사

레이어별로 중첩된 콜백이 있음을 볼 수 있습니다. 이전에 의심했던 코드를 단순화해 보겠습니다.

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' 위의 콜백에 혼동하지 마십시오. 매우 간단한 콜백 함수로 모든 것이 명확하게 설명되어 있습니다. res.end 이후에도 우리 코드는 여전히 계속 다운되어야 합니다. 실제로는 connect의 미들웨어가 양파 모양이라고 할 수 있습니다. , 그러나 동기 코드이기 때문에 일반적으로 이렇게 하는 대신에 connect의 미들웨어 모델을 다시 설명할 수 있습니다.

Koa의 실행 프로세스

마찬가지로 Koa 소스 코드를 분석할 때 언급한 Koa의 미들웨어 모델: Onion Shape

다음 코드를 예로 들어 보겠습니다.

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)

로그인 후 복사

서비스에 액세스하여 출력:

m1
m2
m3
m2 end
m1 end

로그인 후 복사

emm 전에 연결한 기사를 본 적이 있는 것 같습니다. 그리고 여기에서 koa용 미들웨어를 얻었습니다. 두 모델 사이에 차이가 없다는 결론은 나에게도 혼란스럽습니다. 물론 여기에는 koa 미들웨어의 단순화된 모델이 설명되어 있습니다.

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)
})

로그인 후 복사

async/await의 기능이 비동기 작업을 '동기화'하는 것임을 알고 있습니다(그렇게 보이지만 그렇지 않지만 걱정할 필요는 없습니다). 그러면 여기서 Promise는 자연스럽게 '동기화'됩니다. , 이는 console.log(m3 end)의 모든 비동기 작업이 '동기화'될 수 있음을 의미합니다.

결론

결론에 도달하기 전에 실제로 connect의 미들웨어도 양파이기 때문에 생각해 볼 수 있습니다. koa와 동일하게 사용하면 아무런 문제가 없을 것 같습니다. 그러면 우리 서비스가 데이터베이스에 액세스해야 한다고 가정해 보겠습니다. 물론 getUser가 비동기식이라고 가정해 보겠습니다. connect와 koa의 방법은 각각:

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

로그인 후 복사

물론 차이가 없는 것 같습니다. 결론만 말씀드리자면(잠시 보류): connect 미들웨어는 동기식이며 다른 비동기 작업을 '기다리지' 않지만 koa는 가능합니다. 비동기 작업을 '대기'합니다. 물론 기다리지 않으면 문제가 없습니다.