Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
async_graphqlのguardが便利だった話
Search
estie | エスティ
June 05, 2023
Programming
0
1k
async_graphqlのguardが便利だった話
「Rust、何もわからない...#8」
estie | エスティ
June 05, 2023
Tweet
Share
More Decks by estie | エスティ
See All by estie | エスティ
事業価値を作る「攻めるPM、守るPM」
estie
0
87
プレイングにマネジメントに。広がる役割と向き合う中での学び
estie
0
240
デザインと開発を変える、 生成AIとの向き合い方
estie
0
350
Snowflake ML モデルを dbt データパイプラインに組み込む
estie
0
300
ユーザー価値を最大化するための爆速開発
estie
0
160
10年PMをやって気付いた4つのPMタイプ
estie
0
400
自動と手動の両輪で開発するデータクレンジング
estie
2
380
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
350
PMとデザイナーが協働してプロダクトを最速で立ち上げるための一つのメソッド
estie
0
190
Other Decks in Programming
See All in Programming
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
3
1.1k
KessokuでDIでもgoroutineを活用する / Go Connect #6
mazrean
0
140
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
2
980
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
370
1から理解するWeb Push
dora1998
2
270
More Approvers for Greater OSS and Japan Community
tkikuc
1
110
2025 年のコーディングエージェントの現在地とエンジニアの仕事の変化について
azukiazusa1
15
5.9k
Honoアップデート 2025年夏
yusukebe
1
900
【第4回】関東Kaggler会「Kaggleは執筆に役立つ」
mipypf
0
1k
開発チーム・開発組織の設計改善スキルの向上
masuda220
PRO
18
9.7k
詳解!defer panic recover のしくみ / Understanding defer, panic, and recover
convto
0
210
TanStack DB ~状態管理の新しい考え方~
bmthd
2
420
Featured
See All Featured
Being A Developer After 40
akosma
90
590k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6.1k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Writing Fast Ruby
sferik
628
62k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Transcript
async_graphqlのguardが便利だった話 2022/5/22 Rust、何もわからない….vol8 hige_yy @kia5n_y2_mud
higeです。 • 本名は山中です • 202012~ estie • 元々はフロントエンド領域 • オーディオオタク
• ビアポンなるパーティゲームの元日本代表 1
2 1. async_graphqlを使ってGraphQL移行した話 2. 便利だったものの話 3. 大変だったことの話 4. まとめ こういう話しますよ
GraphQLに移行するぞ!!!
4 1. 現状はReact + Rust(REST)の構成だが、ユースケースごとにフロントでリソースの結合 成形を行っている箇所が複数あってちょっとつらい 2. 見た目のちょっとした変更のためにバックエンドまで変更しなければならないことが 多々ある 3.
フィールド単位で参照の権限を設定したいが、似たような実装が毎回必要になる 4. ……etc なぜGraphQLにしたいか 移行したいので検証を実施した - Juniperで試しに実装してみる話 (Rust何もわからないvol.4) - 結果、やりたいことはできそう。
5 Juniper or async_graphqlで検討 差分は大きくなかったが以下が決め手になりasync_graphqlを使うことに - OneofObjectが使える - Inputで値が入ったEnumが使える -
Fieldの定義とGuardが柔軟に行えそう - Fieldごとに設定可能でResolver実行前に実行されるもの 技術選定の話
6 - crateをいくつかにわけて開発 - api - sql - usecase -
middleware - ……etc 元々どんな感じで作っていたか
7 - crateをいくつかにわけて開発 - api <- ここを部分的にgqlに移行 - sql -
usecase - middleware - ……etc どんな感じで移行するか
8 ざっくりと実装はこんなイメージ
9 移行していく 開発チームを一時的に機能開発組と移行組に分割して実施 移行できて嬉しいものから移行していった 結果、1週間と少しで主要な参照が移行完了。 以降、作成されるAPIはgqlになり順次作成・更新系を移行中。
10 運用に移って GraphQLにチーム全員が慣れているわけではないので、ちょくちょくつま づきは起きていますが、おおむね問題なく運用できています。 当初困っていたフロントエンドが複雑になる部分は無事解消されました。
便利だったものの話
12 FieldGuard こう定義して こうやって使う
13 なぜ便利だったかの話 不動産ドメインには多くの登場人物が存在します - ビルを保有する人 - ビルを管理する人 - 募集を出す人 -
営業をする人 - 部屋を借りたい人 - ……etc 同じ“ビル”を指していても全く同じ情報が全てのユーザに見えて良いわけで はありません。
14 なぜ便利だったかの話 ここでは簡単のために以下のユーザが存在していると仮定します - ビルの貸主 - 他社のビルは閲覧できない - テナント -
全てのビルを閲覧できるが見えない項目がある - 管理者 - 全て閲覧可能
15 なぜ便利だったかの話 このようなビルを考える
16 なぜ便利だったかの話 RESTでやっていた時…… -> 全部分けて定義する? -> Optionalな型にして返す?
17 なぜ便利だったかの話 見ても良い条件を満たさない場合Errを返すGuardをユーザごとに作成
18 なぜ便利だったかの話 このように表現可能になります。
19 なぜ便利だったかの話 1. 一見してどのフィールドが誰に公開されているのかわかる 2. 同一のロジックで処理が可能 3. ctxと引数を受けることができるので柔軟なGuardの記述が可能
20 Remote Enum レイヤーを跨ぐ構造体について依存を切るために詰め替えたりしますよね。 でも何度も impl From<~> ……するの結構大変ですよね。 特にenumのこれ
21 Remote Enum remote-enumを使うと実に楽になります。
22 できないこともある 値のあるEnumについては使えません。
23 値のあるEnumについてはどうするか パターン1: Unionを使う 全て値を持っている場合、Unionが使えます。 パターン2: 型を一部諦める 今のところこれは良い!という手段は特になし。
大変だったことの話
25 複雑なSQL操作でAcquireを使うと lifetime error になる これ
26 どういう時に起きるか acquireを要求している関数を複数呼んでいる関数があり
27 どういう時に起きるか それをLoaderで呼び出した場合に起きます
28 どうやって解決したか Acquireを要求していた箇所を MySqlConnectionに変更するととりあ えずCompileは通るようになります。 何がだめなのか……?
29 ちょっと調べてみた cargo-expandを使って 該当箇所をexpandすると……
30 ちょっと調べてみた 一部コメントアウトすると通る
31 ちょっと調べてみた どうやらnotesを引いてるところで こけてるみたい…… 結論わかんない ということがわかりました!
まとめ
33 まとめ 1. async_graphqlのGuardは便利だった。 2. LifetimeのErrorは難しい。sqlxを使うなら気をつけよう。
34 追記 折角なので、sqlx + async_graphqlの環境を作っておきました。 async_graphqlに興味が出た方はいじってみてください。 (あとあのErrorがわかる方の解説もお待ちしてます) https://github.com/savacan/rust-gql-sample
35 estie(エスティ) は オフィス不動産を デジタル化する会社です