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 | エスティ
Platformに“ちょうどいい”責務ってどこ? 関心の熱さにあわせて考える、責務分担のプラクティス
estie
0
48
事業価値を作る「攻めるPM、守るPM」
estie
0
96
プレイングにマネジメントに。広がる役割と向き合う中での学び
estie
0
260
デザインと開発を変える、 生成AIとの向き合い方
estie
0
370
Snowflake ML モデルを dbt データパイプラインに組み込む
estie
0
310
ユーザー価値を最大化するための爆速開発
estie
0
170
10年PMをやって気付いた4つのPMタイプ
estie
0
420
自動と手動の両輪で開発するデータクレンジング
estie
2
390
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
350
Other Decks in Programming
See All in Programming
ユーザーも開発者も悩ませない TV アプリ開発 ~Compose の内部実装から学ぶフォーカス制御~
taked137
0
190
ぬるぬる動かせ! Riveでアニメーション実装🐾
kno3a87
1
230
JSONataを使ってみよう Step Functionsが楽しくなる実践テクニック #devio2025
dafujii
1
640
実用的なGOCACHEPROG実装をするために / golang.tokyo #40
mazrean
1
290
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
4
2.9k
Introducing ReActionView: A new ActionView-compatible ERB Engine @ Rails World 2025, Amsterdam
marcoroth
0
710
Putting The Genie in the Bottle - A Crash Course on running LLMs on Android
iurysza
0
140
詳解!defer panic recover のしくみ / Understanding defer, panic, and recover
convto
0
250
MCPでVibe Working。そして、結局はContext Eng(略)/ Working with Vibe on MCP And Context Eng
rkaga
5
2.3k
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
11
4.4k
個人開発で徳島大学生60%以上の心を掴んだアプリ、そして手放した話
akidon0000
1
150
Amazon RDS 向けに提供されている MCP Server と仕組みを調べてみた/jawsug-okayama-2025-aurora-mcp
takahashiikki
1
120
Featured
See All Featured
Speed Design
sergeychernyshev
32
1.1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
A better future with KSS
kneath
239
17k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
810
The Invisible Side of Design
smashingmag
301
51k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Code Reviewing Like a Champion
maltzj
525
40k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
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(エスティ) は オフィス不動産を デジタル化する会社です