Categorygithub.com/momotaro98/go-codes-for-learningConcurrency-in-Gochapter4_Patterns_of_Go_Concurrencysection12_context
# README
4.12 context package
Value purpose
Contextには何を保管するのに適しているのか、ガイドはcontextパッケージにあるこの少し曖昧なコメントです。
Use context values only for request-scoped data that transits processes and API boundaries, not for passing optional parameters to functions.
この"request-scoped data" (リクエストスコープ) とは何か?
下記は著者の経験則によるもの
1 データはプロセスやAPIの境界を通過すべき
プロセス内のメモリでデータを生成したのなら、そのデータはリクエストスコープのデータとしてはおそらく不適格でしょう。
2 データは不変であるべき
もし不変でないのであれば、定義により保管しようとしているデータはリクエストから来たものではありません。
3 データは単純な型に向かっていくべき
境界を通過した先にいる側がこのデータをずっと簡単に取得できるようにする。
4 データはデータであるべきでメソッド付きの型であるべきではない
操作というのはロジックで、このデータを消費するものに属している。
5 データは装飾の操作を助けるべきものであって、それを駆動するものではない。
あなたのアルゴリズムがContextに含まれるものによって異なった振る舞いをするのであれば、オプションのパラメータが扱うべき領域を侵してしまっているでしょう。
Data | 1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|---|
Request ID | ✅ | ✅ | ✅ | ✅ | ✅ |
User ID | ✅ | ✅ | ✅ | ✅ | |
URL | ✅ | ✅ | |||
API server connection | |||||
Auth Token | ✅ | ✅ | ✅ | ✅ | |
Request Token | ✅ | ✅ | ✅ |
APIサーバへの接続は明らかにContextに保管するべきでないですが、認証トークンについてはどうでしょうか。これはあるチームでは受け入れられるが、別のチームでは受け入れられないかもしれません。
# Functions
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author