Expressとkoaの使用比較-jsチュートリアル-php.cn

Expressとkoaの使用比較

小云云

リリース： 2018-01-27 09:58:25

オリジナル

2716 人が閲覧しました

Express と koa は両方ともサーバーサイド開発フレームワークであり、サーバーサイド開発の焦点は、HTTP リクエストと HTTP レスポンスの 2 つのオブジェクトのカプセル化と処理、アプリケーションのライフサイクルのメンテナンス、およびビューの処理です。

Node.js 開発に関して言えば、Express と koa という 2 つの人気のあるフレームワークについて言及する必要があります。 Express は、使いやすく強力な、シンプルで柔軟な Web 開発フレームワークです。 Koa は、ES6 の新機能に基づいて Express フレームワークのオリジナルチームによって再開発されたアジャイル開発フレームワークであり、現在非常に人気があり、Express に追いつく可能性が非常に高いです。

Express は主に Connect ミドルウェアフレームワークをベースにしており、機能が豊富で使いやすいフレームワーク自体に、ルーティング、ビュー処理などの多数の便利な機能がカプセル化されています。 Koa は主に co ミドルウェアフレームワークに基づいており、フレームワーク自体には多くの機能が統合されていませんが、ES6 ジェネレーター機能に基づいたミドルウェアメカニズムにより、長年批判されてきた問題を解決します。「コールバック地獄」」や厄介なエラー処理の問題は、開発者の間で非常に人気があります。

実は以前、expressとkoaの比較を書きましたが、後でその中に多くの誤りがあることに気づきました。そこで、特にミドルウェア部分の比較について、以前の間違いを修正することを考えています。より単純な Connect は

connect の実行プロセスを置き換えます。通常、connect のミドルウェアモデルは線形である、つまり、以下に示すように 1 つずつ実行されると言われます:

これはもちろん正しいですが、次のコードを実行すると、少し混乱するかもしれません:

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 のミドルウェアは実際にはタマネギ型であると言えます。しかし、これは同期コードであるため、一般的にこれを行う代わりに、接続のミドルウェアモデルを再度記述することができます:

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 と Express のミドルウェアを入手しました。モデル間に違いがないという結論は私にはわかりにくいですが、もちろん違いはあります。結論は後で説明します。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 と同じように使用することに問題はないようです。次に、ユーザーの 1 人が 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 は同様です。もちろん、待機しなくても問題ありません。