make HTTP server with Axum, Rust

Transcript

1. AxumでHTTPサーバ作った 限界LT #int(pi) Speaker: JapaneSe Obaka Notation
2. Table of Contents • 事故紹介 • 前提 • つくったもの • api-shower: the origin • ここがんばったポイント ◦ 状態共有ありのハンドラの実装 ◦ SSE用のAPIの実装 • 話のオチ
3. 自己紹介 • ライガー(JapaneSe Obaka Notation) • 𝕏: @ahoxa1rx • Github: raiga0310 • ぽーとふぉりお: https://raiga0310.github.io • B3 • Like: Rust TS • フロントは苦手意識
4. 前提 • 誤解を招く表現を使っているかもしれない(正しく理解しているとは言えないので) • ❌何もしらない人向け ❌上級者向け 🔴初心者→中級者向け くらいのテンション • 7月中旬くらいのほぼ最新のバージョン使ってる 最新版は知らん
5. つくったもの • https://github.com/raiga0310/api-shower • https://github.com/raiga0310/front-shower • 寮に住んでる兄がシャワーの空きが知りたいとぼやいていたのでなんとなくで作っ た • (dyn 要件)
6. 動作画面 • シンプルなデザイン() • フィルタ機能付き • おいそこ表の空欄表示してるなとか言うな
7. 構成 • バックエンド ◦ Rust + Axum: APIサーバ ◦ PostgreSQL: DB • フロントエンド ◦ JS + Svelte ▪ pnpm + Vite • インフラ ◦ Nginx: ルーティング管理 ゆくゆくはHTTPS対応とか見越して ◦ Docker: バックエンドをまとめるやつ • DevOps(?) ◦ Github Actions: 正直ぐちゃぐちゃなので直したい (チェックに10分はごみ) ◦ Codecov: おまえなに
8. 構成その2 レポジトリパターンみたいなやつ MVCっぽくもなってる(フロントは別で)
9. APIエンドポイント的な話 GET /{...filter}/showerroomsで特定の区画の施設の空き状況がわかるよ PATCH /{...filter}/showerroomsで特定の区画の空き状況を更新するよ 他にも実装してるけど使う側に取ってはこのくらいで十分かなって(あとはコード読んで)
10. 通信の流れ
11. api-shower: the origin もともとTodoアプリの実装から発想を得ているのでアーキテクチャやら設計はかなりシ ンプル レポジトリパターンみたいなやつ 少しバージョンは古いので要注意 大体の機能はそのまま使えるはず https://github.com/AkifumiSato/learn-rust-with-web-application
12. ここ頑張ったポイント: 型引数ありの状態共有ハンドラ 記事読んで(ダイマ) https://qiita.com/raiga0310/items/889b4cb6e3226d2f1358
13. ふわっと説明 Axumのミドルウェアへの追加をする DBとのやり取りのためのデータへのアクセスを許可するためのwith_state() (旧バー ジョンはレイヤー追加だった) ハンドラの引数の順番は決まっているので気をつけよう
14. ここ頑張ったポイント: SSE用のAPIの実装 記事読んで(大胆な天丼は乙女の特権) https://qiita.com/raiga0310/items/f3793dbb29c7bd069b8c
15. ふわっと説明 DB更新をもとにユーザーに変更が通知されなければならない クライアントからの定期リロード → 通信の無駄が多い WebSocketなどの双方向通信プロトコル → 実装面倒(プロトコル変わるし) あと単方向 でいい ⇒Server Sents Eventを使いました(tokioは神) 付記: actix-webだとExperimental(actix-web-lab)にSSEハンドラが実装されてる
16. 具体的なコード: ルーティング
17. 具体的なコード: ハンドラ(GET)
18. 具体的なコード: DB更新
19. 具体的なコード:SSE struct Event
20. 具体的なコード: SSE 更新+通知部分
21. 苦痛に耐えられぬとき､読むとよい • https://docs.rs/axum/0.6.19/axum/ • https://github.com/tokio-rs/axum/tree/v0.6.x • https://developer.mozilla.org/ja/docs/Web/HTTP • https://developer.mozilla.org/ja/docs/Web/API/Server-sent_events/Using_serv er-sent_events • https://developer.mozilla.org/ja/docs/Web/API/Server-sent_events https://www.pixiv.net/artworks/78785573
22. 話のオチ てっきり各階に複数個シャワールームあるんじゃないかとか勝手に思って設計した →｢寮で男子5室女子3室だぞ｣ やるならちゃんと､要件を聞こうね!!(京都への旅費をふんだくりました)
23. 説明パート‐API • Application Interface Programmingの略 • ソフトウェアとユーザー以外のなにかのつなぐ仲介者 • フロントとバック(DB)をつなぐのもAPIだし • WebAPIというと､HTTP通信やらのデータのやり取りがおおい多分 • HTTP/1.1 GET /hello とかなんとか書かれてるやつ(は?) • ブラウザの窓のURLもAPIを叩いている(GET)
24. 説明パート‐HTTP • OSI参照モデルの一番上での通信 を担当 • HyperTextTranferProtocol • HTTP （ Hypertext Transfer Protocol ）は、分散型の協 調 的なハイパーテキスト情報システム用の， ステートレスな アプリケーションレベルのプロトコルである (RFC 7231(訳)) • Web系API大体これ使ってる (ド偏見) • 最近は新しいバージョンとかもあるらしいけど､旧タイプの 人間なので1.1を使います
25. 説明パート‐HTTP リクエスト･レスポンスについて • インターネット通信にはリクエストとレスポン スがある(要求と返信) • それぞれヘッダがありメタ情報が格納されて いる(メタ情報:データに付随する情報) • ブラウザでは開発者モード(firefoxだと Ctrl+Shift+I)のnetworkタブで確認可能
26. HTTPメソッド HTTP通信における振る舞いの事 GET/POST/PATCH/PUT/DELETE/...大体ひつようなものは揃っている 別に全部GETでもできることはできると思うけど､ちゃんと特化仕様になってるからしたい こととHTTPメソッドは統一しような
27. 説明パート‐*エンド*系について 日本人的にはエンドって終わりだけのイメージがある なぜかプログラミングの文脈ではよく端点くらいの解釈で扱われる用語 例: フロントエンド､バックエンド: いわずもがな､データの流れの端点(終わりがフロント､ 始まりがバック) APIエンドポイント : これ僕よくわかってない(おい) 叩く場所がこれなんだと思う
28. CRUD データの扱いに対する作成､取得､更新､削除(Create/Read/Update/Delete)の頭文字 を取ったもの シンプルなデータの扱いであればこの管理を定義するのが楽 HTTPメソッドではある程度表現できる 操作 HTTPメソッド Create POST Read GET Update PUT､PATCH Delete DELETE
29. 説明パート-MVCパターン やることを分離したときのパターンの一つ｡ データを保持するModel データやレスポンスの情報を表示するView リクエストに対する適切な処理をするController の3つで構成される｡伝統的な分離モデル
30. 説明パート‐xDD Driven Developmentの略DDD(Domein-DD)､TDD(Test‐DD)とか､何を基準に開発す るのかということ 僕の好みはTDDとCDD(Compile‐DD)
31. 説明パート-CI/CD 継続的インテグレーション･継続的デプロイ ソフトウェアの品質の維持やデプロイ･ローンチの自動化のやつ できるとだいぶ楽 GithubはこのCI/CDをActionsとかで提供しているPRにかませると助かることが多い
32. 二人の環境差異をなくす Docker 任意のマシンで動かせるように実行環境自体を一つのコンテナとして提供するサービス DockerのあるOSであればDockerで動くものはなんでも動かせる 複数のサービスをComposeなどでまとめて動かせる(大規模だとkubernetes(k8s)とか を使う) (人はDockerがインストールできないのが唯一の欠点 )
33. VSCode拡張機能 ThunderClient HTTP通信を試したいときに便利 insomniaとかみたくPCにインストー ルしないので楽
34. Rustパート‐Cargoとかそこら辺 • Cargo 色々やってくれる テスト､フォーマット､ビルド､実行､ドキュメント作成､クレート の公開 • Clippy したほうがいいことを提示してくれる • sqlx RustにおけるDBマイグレーションをサポート
35. Rustパート:構造体､メソッド ひとまとめにしたいデータをまとめるためのもの それぞれの変数はメンバとか言われてる(OOの文脈) メソッドは`impl Hoge`の中に
36. Rustパート-ジェネリクス 複数の型を受け入れるようにするための仕組み 便利なデータ構造体とかをいろんな型で使えるよう にしたいとか(再利用性) `<T>`で記す
37. Rustパート-トレイト 違う型や構造体へ共通の振る舞いを提供した いときの機能 このトレイトのお陰で､｢特定のメソッドをもつ｣ 型という曖昧な引数を関数に取ることができる
38. Rustパート‐トレイトを満たす引数 処理中に一定の動作が任意の型に必 要な場合､それをトレイトに抽出して書 くとコードがシンプルになる
39. Rustパート-Result エラーの処理を扱う(エラーハンドリング) I/Oとかの失敗するやつに囲っておくと ､Ok(T)とかErr (成功時､失敗時)が返る こまったらunwrap()しとこうね･･････(<ーこいつは火炙りにかけたほうがいい)
40. クレート､モジュール Rustのライブラリ系の名称 色々書き方はあるが､性質が似ているものとか､そこで扱う便利な関数群をまとめておく
41. Rustパート‐tokio Rustのサードパーティ()の非同期ランタイムを提供するクレート もう非同期ならぜんぶこいつでいいだろ いろんなI/O使うクレートはtokio依存なことが多い 便利だからね
42. Rustパート-Axum RustにおけるWebバックエンドフレームワーク (感想)機能ごとにまとめるのが楽なイメージ､Actix-webは理論上散らかしてもいいのが ちょっと不安要素かなって ルーターにレイヤーを重ねることで認証や状態共有などのミドルウェアのサポートとかが できる
43. 説明パート‐実装 ハンドラ handleが扱うみたいな意味があるので､handlerはよくプログラムにおいて総合的な処 理部分という認識で扱われる 記事とかでも~~するハンドラみたいな言い方する意識高い系はおおい(は?)