make HTTP server with Axum, Rust

Slide 1

Slide 1 text

AxumでHTTPサーバ作った限界LT #int(pi) Speaker: JapaneSe Obaka Notation

Slide 2

Slide 2 text

Table of Contents ● 事故紹介 ● 前提 ● つくったもの ● api-shower: the origin ● ここがんばったポイント ○ 状態共有ありのハンドラの実装 ○ SSE用のAPIの実装 ● 話のオチ

Slide 3

Slide 3 text

自己紹介 ● ライガー(JapaneSe Obaka Notation) ● 𝕏: @ahoxa1rx ● Github: raiga0310 ● ぽーとふぉりお: https://raiga0310.github.io ● B3 ● Like: Rust TS ● フロントは苦手意識

Slide 4

Slide 4 text

前提 ● 誤解を招く表現を使っているかもしれない(正しく理解しているとは言えないので) ● ❌何もしらない人向け ❌上級者向け 🔴初心者→中級者向けくらいのテンション ● 7月中旬くらいのほぼ最新のバージョン使ってる最新版は知らん

Slide 5

Slide 5 text

つくったもの ● https://github.com/raiga0310/api-shower ● https://github.com/raiga0310/front-shower ● 寮に住んでる兄がシャワーの空きが知りたいとぼやいていたのでなんとなくで作った ● (dyn 要件)

Slide 6

Slide 6 text

動作画面 ● シンプルなデザイン() ● フィルタ機能付き ● おいそこ表の空欄表示してるなとか言うな

Slide 7

Slide 7 text

構成 ● バックエンド ○ Rust + Axum: APIサーバ ○ PostgreSQL: DB ● フロントエンド ○ JS + Svelte ■ pnpm + Vite ● インフラ ○ Nginx: ルーティング管理ゆくゆくはHTTPS対応とか見越して ○ Docker: バックエンドをまとめるやつ ● DevOps(?) ○ Github Actions: 正直ぐちゃぐちゃなので直したい (チェックに10分はごみ) ○ Codecov: おまえなに

Slide 8

Slide 8 text

構成その2 レポジトリパターンみたいなやつ MVCっぽくもなってる(フロントは別で)

Slide 9

Slide 9 text

APIエンドポイント的な話 GET /{...filter}/showerroomsで特定の区画の施設の空き状況がわかるよ PATCH /{...filter}/showerroomsで特定の区画の空き状況を更新するよ他にも実装してるけど使う側に取ってはこのくらいで十分かなって(あとはコード読んで)

Slide 10

Slide 10 text

通信の流れ

Slide 11

Slide 11 text

api-shower: the origin もともとTodoアプリの実装から発想を得ているのでアーキテクチャやら設計はかなりシンプルレポジトリパターンみたいなやつ少しバージョンは古いので要注意大体の機能はそのまま使えるはず https://github.com/AkifumiSato/learn-rust-with-web-application

Slide 12

Slide 12 text

ここ頑張ったポイント: 型引数ありの状態共有ハンドラ記事読んで(ダイマ) https://qiita.com/raiga0310/items/889b4cb6e3226d2f1358

Slide 13

Slide 13 text

ふわっと説明 Axumのミドルウェアへの追加をする DBとのやり取りのためのデータへのアクセスを許可するためのwith_state() (旧バージョンはレイヤー追加だった) ハンドラの引数の順番は決まっているので気をつけよう

Slide 14

Slide 14 text

ここ頑張ったポイント: SSE用のAPIの実装記事読んで(大胆な天丼は乙女の特権) https://qiita.com/raiga0310/items/f3793dbb29c7bd069b8c

Slide 15

Slide 15 text

ふわっと説明 DB更新をもとにユーザーに変更が通知されなければならないクライアントからの定期リロード → 通信の無駄が多い WebSocketなどの双方向通信プロトコル → 実装面倒(プロトコル変わるし) あと単方向でいい ⇒Server Sents Eventを使いました(tokioは神) 付記: actix-webだとExperimental(actix-web-lab)にSSEハンドラが実装されてる

Slide 16

Slide 16 text

具体的なコード: ルーティング

Slide 17

Slide 17 text

具体的なコード: ハンドラ(GET)

Slide 18

Slide 18 text

具体的なコード: DB更新

Slide 19

Slide 19 text

具体的なコード:SSE struct Event

Slide 20

Slide 20 text

具体的なコード: SSE 更新+通知部分

Slide 21

Slide 21 text

苦痛に耐えられぬとき､読むとよい ● 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

Slide 22

Slide 22 text

話のオチてっきり各階に複数個シャワールームあるんじゃないかとか勝手に思って設計した →｢寮で男子5室女子3室だぞ｣やるならちゃんと､要件を聞こうね!!(京都への旅費をふんだくりました)

Slide 23

Slide 23 text

説明パート‐API ● Application Interface Programmingの略 ● ソフトウェアとユーザー以外のなにかのつなぐ仲介者 ● フロントとバック(DB)をつなぐのもAPIだし ● WebAPIというと､HTTP通信やらのデータのやり取りがおおい多分 ● HTTP/1.1 GET /hello とかなんとか書かれてるやつ(は?) ● ブラウザの窓のURLもAPIを叩いている(GET)

Slide 24

Slide 24 text

説明パート‐HTTP ● OSI参照モデルの一番上での通信を担当 ● HyperTextTranferProtocol ● HTTP （ Hypertext Transfer Protocol ）は、分散型の協調的なハイパーテキスト情報システム用の，ステートレスなアプリケーションレベルのプロトコルである (RFC 7231(訳)) ● Web系API大体これ使ってる (ド偏見) ● 最近は新しいバージョンとかもあるらしいけど､旧タイプの人間なので1.1を使います

Slide 25

Slide 25 text

説明パート‐HTTP リクエスト･レスポンスについて ● インターネット通信にはリクエストとレスポンスがある(要求と返信) ● それぞれヘッダがありメタ情報が格納されている(メタ情報:データに付随する情報) ● ブラウザでは開発者モード(firefoxだと Ctrl+Shift+I)のnetworkタブで確認可能

Slide 26

Slide 26 text

HTTPメソッド HTTP通信における振る舞いの事 GET/POST/PATCH/PUT/DELETE/...大体ひつようなものは揃っている別に全部GETでもできることはできると思うけど､ちゃんと特化仕様になってるからしたいこととHTTPメソッドは統一しような

Slide 27

Slide 27 text

説明パート‐*エンド*系について日本人的にはエンドって終わりだけのイメージがあるなぜかプログラミングの文脈ではよく端点くらいの解釈で扱われる用語例: フロントエンド､バックエンド: いわずもがな､データの流れの端点(終わりがフロント､始まりがバック) APIエンドポイント : これ僕よくわかってない(おい) 叩く場所がこれなんだと思う

Slide 28

Slide 28 text

CRUD データの扱いに対する作成､取得､更新､削除(Create/Read/Update/Delete)の頭文字を取ったものシンプルなデータの扱いであればこの管理を定義するのが楽 HTTPメソッドではある程度表現できる操作 HTTPメソッド Create POST Read GET Update PUT､PATCH Delete DELETE

Slide 29

Slide 29 text

説明パート-MVCパターンやることを分離したときのパターンの一つ｡データを保持するModel データやレスポンスの情報を表示するView リクエストに対する適切な処理をするController の3つで構成される｡伝統的な分離モデル

Slide 30

Slide 30 text

説明パート‐xDD Driven Developmentの略DDD(Domein-DD)､TDD(Test‐DD)とか､何を基準に開発するのかということ僕の好みはTDDとCDD(Compile‐DD)

Slide 31

Slide 31 text

説明パート-CI/CD 継続的インテグレーション･継続的デプロイソフトウェアの品質の維持やデプロイ･ローンチの自動化のやつできるとだいぶ楽 GithubはこのCI/CDをActionsとかで提供しているPRにかませると助かることが多い

Slide 32

Slide 32 text

二人の環境差異をなくす Docker 任意のマシンで動かせるように実行環境自体を一つのコンテナとして提供するサービス DockerのあるOSであればDockerで動くものはなんでも動かせる複数のサービスをComposeなどでまとめて動かせる(大規模だとkubernetes(k8s)とかを使う) (人はDockerがインストールできないのが唯一の欠点 )

Slide 33

Slide 33 text

VSCode拡張機能 ThunderClient HTTP通信を試したいときに便利 insomniaとかみたくPCにインストールしないので楽

Slide 34

Slide 34 text

Rustパート‐Cargoとかそこら辺 ● Cargo 色々やってくれるテスト､フォーマット､ビルド､実行､ドキュメント作成､クレートの公開 ● Clippy したほうがいいことを提示してくれる ● sqlx RustにおけるDBマイグレーションをサポート

Slide 35

Slide 35 text

Rustパート:構造体､メソッドひとまとめにしたいデータをまとめるためのものそれぞれの変数はメンバとか言われてる(OOの文脈) メソッドは`impl Hoge`の中に

Slide 36

Slide 36 text

Rustパート-ジェネリクス複数の型を受け入れるようにするための仕組み便利なデータ構造体とかをいろんな型で使えるようにしたいとか(再利用性) ``で記す

Slide 37

Slide 37 text

Rustパート-トレイト違う型や構造体へ共通の振る舞いを提供したいときの機能このトレイトのお陰で､｢特定のメソッドをもつ｣型という曖昧な引数を関数に取ることができる

Slide 38

Slide 38 text

Rustパート‐トレイトを満たす引数処理中に一定の動作が任意の型に必要な場合､それをトレイトに抽出して書くとコードがシンプルになる

Slide 39

Slide 39 text

Rustパート-Result エラーの処理を扱う(エラーハンドリング) I/Oとかの失敗するやつに囲っておくと､Ok(T)とかErr (成功時､失敗時)が返るこまったらunwrap()しとこうね･･････(<ーこいつは火炙りにかけたほうがいい)

Slide 40

Slide 40 text

クレート､モジュール Rustのライブラリ系の名称色々書き方はあるが､性質が似ているものとか､そこで扱う便利な関数群をまとめておく

Slide 41

Slide 41 text

Rustパート‐tokio Rustのサードパーティ()の非同期ランタイムを提供するクレートもう非同期ならぜんぶこいつでいいだろいろんなI/O使うクレートはtokio依存なことが多い便利だからね

Slide 42

Slide 42 text

Rustパート-Axum RustにおけるWebバックエンドフレームワーク (感想)機能ごとにまとめるのが楽なイメージ､Actix-webは理論上散らかしてもいいのがちょっと不安要素かなってルーターにレイヤーを重ねることで認証や状態共有などのミドルウェアのサポートとかができる

Slide 43

Slide 43 text

説明パート‐実装ハンドラ handleが扱うみたいな意味があるので､handlerはよくプログラムにおいて総合的な処理部分という認識で扱われる記事とかでも~~するハンドラみたいな言い方する意識高い系はおおい(は?)