abstractions.とある。本質だと思っており、WEBサーバーはリクエストを受け付けて非同期にレスポンスを返すものなのでそれを忠実に表したモデルと言える。呼び出すことでロジックを実行する。するかどうかのチェックに使う。主人公なのでここではcallに注目して見ていく。実行させられることにある。その結果、ロジックを各サービスとして分離させて開発できるようになる。外側(つまりユーザーが書いたコードのエントリポイント)にあるtokioなどの非同期ランタイムがpollを解決してくれている。その積み方であるが、それは入れ子である。いう形式にする必要はあるのだろうか。渡してもいいはずである。このやり方でもロジックを積み上げることはできている。いうのを用意させている。その理由や嬉しさについて見ていこう。ついて深く理解するために公式は次の2つのドキュメントを紹介している。https://github.com/tower-rs/tower/blob/master/guides/building-a-middleware-from-scratch.mdhttps://tokio.rs/blog/2021-05-14-inventing-the-service-trait詳しくはこれを読んでもらえるといいのだが、自分の発表はこの2つのドキュメントの理解が前提条件にあるので簡単にまとめようと思う。モチベーションを知ろうというドキュメントだ。applicationserver.run(the_users_application).await?;という設計になるであろうことが書かれている。無限繰り返しで行う必要があることHTTPサーバーのハンドラはリクエストを受け取り、レスポンスのFutureを返すものであることから、このようなデザインに落ち着くだろうと自分は納得している。関数合成でサーバーに機能を追加するこのサーバーに機能を足していこう。拡張していくことになる。関数に備わって欲しい具体的な機能はルーティングだろう。}}ここにさまざまな横断的な機能を足してみよう。タイムアウト機能も足したいとする。}}のようにして実現できる。中でhandle_requestを読んでいることに注目して欲しい。返すようにしたいとする。読んでいることに注目して欲しい。処理を切り出しておいて、それを順番に呼び出すことで実現する。このやり方は関数に関数をハードコートしているので再利用性が低くスケーリングさせにくいのと、テストもしにくいといった明確な欠点がある。実装したものをわたすアプローチを考える。実装する構造体は好きな形を選べるので、汎用性は広がる。関数はこのように表現できる。}}のようにして表現できる。以外も実行できるようになって汎用性が高まっている。}}として定義できる。実装上の制約でそうしている。詳しくは原文を見て欲しい。},}をわたすだけで良い。実装されているのでこれで動く。ここでここまでで定義していたHandlerだが、Timeoutのような機能はサーバーに限らずクライアント側でも使える。ようなHandlerはそうだろう。受け取るものとしてモデル化できるからだ。いう名前で呼ぶことにしよう。Self::Future;}という定義になる。呼ばれる仕組みの実現に使う。RateLimitを設けるときに「このcallを呼び出していいか?」をチェックする関数だ。関数を連鎖して呼ぶには関数の入れ子にしていた。これはある関数から別の関数を直接呼ぶと密結合になることから避けたいパターンであった。詳細を知らなくて済み疎結合にできる。実行するかどうかのチェックを挟む機構も備えられるようになるという発明もできる。基本的に自作しなくていい。あることが前提であり、poll_readyは完全にinnerに依存している。頼らない実装をするのである。して用意してくれている。なることが最初から保障されている。頼らない形でベタ書きしている。ようなFWを使えばそのようなことも考えなくて済む。ソースコードはこちらです。このサイトはGatsbyで作られています。