Skip to content

Commit b97fb1c

Browse files
committed
feat(connect): middlewareについて
1 parent 8cb4914 commit b97fb1c

File tree

1 file changed

+45
-0
lines changed

1 file changed

+45
-0
lines changed

ja/connect/README.md

+45
Original file line numberDiff line numberDiff line change
@@ -49,3 +49,48 @@ Echoサーバでは `req.pipe(res);` という形でリクエストをそのま
4949

5050
> **Note** _middleware_となる関数の引数が4つであると、それはエラーハンドリングの_middleware_とするという、Connect独自のルールがあります。
5151
52+
## どういう仕組み
53+
54+
Connectの_middleware_がどのような仕組みで動いているのかを見ていきます。
55+
56+
`app`に登録した_middleware_は、リクエスト時に呼び出されているので、
57+
`app`のどこかに利用する_middleware_を保持していることは推測できると思います。
58+
59+
Connectでは`app.stack`にまだに_middleware_が保持されています。
60+
次のような`app.stack`の中身を表示見ることで、_middleware_が登録順で保持されていることがわかります。
61+
62+
[import connect-trace-example.js](../../src/connect/connect-trace-example.js)
63+
64+
後は、サーバへリクエストがやってきた時に、それぞれの_middleware_を順番に呼び出しています。
65+
66+
上記の例だと以下の順番で_middleware_が呼び出されることになります。
67+
68+
- errorHandler
69+
- nosniff
70+
- hello
71+
72+
エラーハンドリングの_middleware_はエラー時のみ呼ばれるため例外なので、
73+
[nosniff.js](#nosniff.js) -> [hello.js](#hello.js) と呼び出されます。
74+
75+
[import nosniff.js](../../src/connect/nosniff.js)
76+
77+
`nosniff.js`は、処理が終わったら`next()`を呼び出していて、
78+
この`next()`が次の_middleware_へ行くという意味になります。
79+
80+
次に、`hello.js`を見てみると、`next()`がないことがわかります。
81+
82+
[import hello.js](../../src/connect/hello.js)
83+
84+
`next()`がないということは`hello.js`がこの連続する_middleware_の最後となっていることがわかります。
85+
仮に、これより先に_middleware_が登録されていたとしても無視されます。
86+
87+
このような_middleware_を繋げた形を_middleware stack_と呼ぶことがあります。
88+
89+
HTTPサーバではこのような_middleware stack_を作って使うものは既にあり、
90+
PythonのWSGI MiddlewareやRubyのRackなどが該当します。
91+
92+
Connectは`use`というメソッドで_middleware_を使うことからも分かりますが、
93+
Rackを参考にして実装されています。
94+
95+
- [Ruby - Rack解説 - Rackの構造とRack DSL - Qiita](http://qiita.com/higuma/items/838f4f58bc4a0645950a#2-5 "Ruby - Rack解説 - Rackの構造とRack DSL - Qiita")
96+

0 commit comments

Comments
 (0)