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
PyCon Kyushu 2022「Python で gRPC 入門 ~ chat を実装して...
Search
nisshi.dev | にっし
January 22, 2022
Programming
1
780
PyCon Kyushu 2022「Python で gRPC 入門 ~ chat を実装してみるハンズオン~」
2022/1/22(土)に熊本城ホールで行われたPyCon Kyushu 2022のイベントで発表した資料です。
nisshi.dev | にっし
January 22, 2022
Tweet
Share
More Decks by nisshi.dev | にっし
See All by nisshi.dev | にっし
高専ロボコンから始まった私のもの創り
nishidayoshikatsu
0
55
WebXRとは何か
nishidayoshikatsu
0
31
nisshi.dev 自己紹介スライド v0.1
nishidayoshikatsu
0
49
Web×3DのUI表現を模索してみる話
nishidayoshikatsu
0
130
「孤独からの解放」 を目指してShareBrowseを開発している話
nishidayoshikatsu
0
240
Code_for_Yamaguchiの今までとこれから
nishidayoshikatsu
0
850
自己実現ピッチ
nishidayoshikatsu
1
83
Other Decks in Programming
See All in Programming
CursorとDevinが仲間!?AI駆動で新規プロダクト開発に挑んだ3ヶ月を振り返る / A Story of New Product Development with Cursor and Devin
rkaga
5
1.5k
Proxmoxをまとめて管理できるコンソール作ってみました
karugamo
1
320
【TSkaigi 2025】これは型破り?型安全? 真実はいつもひとつ!(じゃないかもしれない)TypeScript クイズ〜〜〜〜!!!!!
kimitashoichi
1
110
TSConfigからTypeScriptの世界を覗く
planck16
1
940
AWS Summit Hong Kong 2025: Reinventing Programming - How AI Transforms Our Enterprise Coding Approach
dwchiang
0
150
Road to Ruby for A Linguistics Nerd
hayat01sh1da
PRO
0
390
最速Green Tea 🍵 Garbage Collector
kuro_kurorrr
1
160
Instrumentsを使用した アプリのパフォーマンス向上方法
hinakko
0
260
ドメイン駆動設計とXPで支える子どもの未来 / Domain-Driven Design and XP Supporting Children's Future
nrslib
0
340
Duke on CRaC with Jakarta EE
ivargrimstad
1
410
バイラテラルアップサンプリング
fadis
3
650
プロダクトエンジニアのしごと 〜 受託 × 高難度を乗り越えるOptium開発 〜
algoartis
0
250
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Cost Of JavaScript in 2023
addyosmani
49
7.9k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Art of Programming - Codeland 2020
erikaheidi
54
13k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Done Done
chrislema
184
16k
Faster Mobile Websites
deanohume
307
31k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Thoughts on Productivity
jonyablonski
69
4.6k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.5k
Agile that works and the tools we love
rasmusluckow
329
21k
Transcript
PythonでgRPC入門 ~web chatを実装してみるハンズオン~ Yoshikatsu Nishida 2022.01.22
プロローグ - 本日話すこと、話さないこと -
プロローグ -本日話すこと、話さないこと - 「gRPC何もわからん...」状態の人が、「gRPCチョットワカル」ようになる! ❌ 厳密な定義説明 ❌microservices VS monorepo ❌本番環境でのgRPCの運用方針
アジェンダ 1. プロローグ 2. 従来のREST APIの世界 3. gRPC入門 4. gRPC
✖ pythonでweb chatを実装してみるハンズ オン
自己紹介 nishida / Yoshikatsu Nishida ・起業準備中の学生エンジニア(B4) ・3E株式会社 R&Dユニット/インターン ・Code for
Yamaguchi創設者, CivicTechForum 2021登壇, 山口県コロナサイト立ち上げ ・NHK高専ロボコンOB ・全日本珠算技能競技大会(そろばん)元島根県代表 ・Next.js, Nest.js, React Native, Firebase, GCP, RoR, Python ・趣味はゲーム(スマブラSP)、旅行 @nsd244 nishidayoshikatsu
従来のREST APIの世界 ・REST APIとは ・REST APIで開発者達が享受したもの ・REST APIで開発者達が抱えている課題 ・REST API開発における便利ツール
REST APIとは REST API(RESTful API)は、基本的に「RESTの原則」に従って設計されている APIのこと ・アドレス可能性: すべての情報が一意な URIで表現されるようにすること ・ステートレス性:
すべてのHTTPリクエストが完全に分離している性質であること ・接続性: ある情報に「別の情報へのリンク」を含めることができること ・統一インターフェース : すべてHTTPメソッドを利用すること( GET, POST, PUT, DELETE)
REST APIで開発者達が享受したもの ・ネイティブアプリケーションへの対応が容易 ・サーバー / クライアント間が疎結合になるため、スケーラビリティが向上する などなど...
REST APIで開発者達が抱えている課題 ・設計の自由度が高い反面、実装ルールの統一性がない →理解しないまま作ると統一性のない APIが生まれてしまう ・仕様や定義に関する要素がない →ドキュメントとの乖離が発生しやすい
REST API開発における便利ツール ・design(設計): postman, stoplight, swagger ・documentation(ドキュメント管理): postman, stoplight, swagger
・build, debug api: postman, stoplight, swagger ・mock server: prism, MSW ※auto generate(自動生成) code→document: ORM(prisma等)が生成, フレームワーク(django等)が生成 document→code: postman等のdocumentation toolが生成
gRPC入門 ・そもそもRPCって何? ・gRPCとは ・採用事例 ・gRPCの特徴 ・ Protocol Buffersによる実装 ・HTTP/2による高速な通信 ・複数のストリーミング通信形式を選択できる
・gRPCで開発者達が抱えている課題
そもそもRPCって何? RPC = Remote Procedure Call(遠隔手続き呼び出し) ・あるプログラムが別のネットワーク上のプログラムを呼び出して実行すること (補足)2つのシステム間の通信パターン(Enterprise Integration Patternsより引用)
1. File Transfer: ファイル転送でのデータ連携 2. Shared Database: データベース共有でのデータ連携 3. Remote Procedure Invocation: 別名Remote Procedure Call(RPC) 4. Messaging: 非同期を前提としたフレームワークを介してデータ連携する, Pub/Subパターン
gRPCとは Googleが2015年2月に公開した、HTTP/2を利用したRPCフレームワーク ・Microservicesに適した高いパフォーマンスを実現する通信プロトコルを目指す ・Stubbyという、Googleが自社DCで活用していたRPCフレームワークがベースになっている マスコットキャラのパンケーキくん (Golden RetrieverのPanCakes)
採用事例 Googleはもとより、国内外にかかわらず多くの採用事例がある ・Google ・Netflix ・Docker ・merukari ・cookpad
gRPCの特徴 ・Protocol Buffersによる実装 ・HTTP/2による高速な通信 ・複数のストリーミング通信形式を選択できる
gRPCの特徴 - Protocol Buffersによる実装 - ・Googleが開発したシリアライズフォーマット ・IDL(インターフェース記述言語)により、任意の言語のクライアント / サーバー用のコードを生成 ・型安全なスキーマ
・JSONなど他のシリアライズフォーマットと比べ、通信量が少なく高速
gRPCの特徴 - HTTP/2による高速な通信 - - HTTP/1.1のパフォーマンス的な課題を解決するために開発された ・gRPCはHTTP/2の上で動作 ・従来通りのRequest/Response形式だけでなく、Streamingを用いた双方向通信も可能 ・データ転送量の圧縮
gRPCの特徴 - 複数のストリーミング通信形式を選択できる - - Unary RPC: 1つのrequestに対して1つのresponse Client Streaming
RPC: 複数のrequestに対して1つのresponse Server Streaming RPC: 1つのrequestに対して複数のresponse Bi-directional Streaming RPC: 複数のrequestに対して複数のresponse 双方向ストリーム? 👀Websocket
gRPCの特徴 - 複数のストリーミング通信形式を選択できる - - gRPCは、ClientとServerがある ・Client ・requestを送信し、responseを受け取る ・内部的にServerのStub(生成されたコード)を保持している ・Server
・requestを受け、responseを返却する
gRPCで開発者達が抱えている課題 - ・HTTP/1との下位互換性がない →システム内でHTTP/2未対応のものがある場合に利用できない →ブラウザ側はgRPCが使えるように対応されていない( gRPC Web, gRPC Web Proxyを利用すれば解決)
・responseの中身を確認するのに専用のクライアントツールが必要 →curlで簡単に確認できる RESTとの差になる
REST APIで開発者達が抱えていた課題 ・設計の自由度が高い反面、実装ルールの統一性がない →理解しないまま作ると統一性のない APIが生まれてしまう→解決 ・仕様や定義に関する要素がない →ドキュメントとの乖離が発生しやすい →解決
gRPC ✖ pythonでweb chatを実装してみるハンズオン ・まずは完成品のデモ ・手元での動かし方 ・コード作成の流れ ・コード解説
まずは完成品のデモ
手元での動かし方 https://github.com/nishidayoshikatsu/pycon_kyushu_2022_kumamoto_grpc_handson
コード作成の流れ 1. .protoファイルを作成(プロトコルの定義) 2. codegen.pyを実行して.protoファイルからコードを自動生成する (protocol bufferへの変換) 3. gRPC ClientとgRPC
Serverをかく 生成!
コード解説 ① = の後に書かれているのは初期値やデフォルト値ではなく、「タグ」という背番号。 ②ChatStream⇦Server Streaming RPC, SendNote ⇦Unary RPC
① ②
コード解説 ChatStream: 新しいメッセージを送信するために使用されるストリーム SendNote: クライアントがサーバーにチャットを送信するときに使用
まとめ - gRPCの想定利用シーン - ・高速な通信(HTTP/2 + protobuf) ・スキーマファーストな開発が可能 ・さまざまな通信方式に対応 よって、
・Microservices間の通信をする場合 ・ネイティブアプリの開発 ・パフォーマンスが求められる場合 ・Microservicesで色々な言語を使いたい場合