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
740
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
50
WebXRとは何か
nishidayoshikatsu
0
27
nisshi.dev 自己紹介スライド v0.1
nishidayoshikatsu
0
44
Web×3DのUI表現を模索してみる話
nishidayoshikatsu
0
120
「孤独からの解放」 を目指してShareBrowseを開発している話
nishidayoshikatsu
0
210
Code_for_Yamaguchiの今までとこれから
nishidayoshikatsu
0
760
自己実現ピッチ
nishidayoshikatsu
1
79
Other Decks in Programming
See All in Programming
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
120
さいきょうのレイヤードアーキテクチャについて考えてみた
yahiru
3
740
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
250
富山発の個人開発サービスで日本中の学校の業務を改善した話
krpk1900
4
380
『GO』アプリ バックエンドサーバのコスト削減
mot_techtalk
0
140
“あなた” の開発を支援する AI エージェント Bedrock Engineer / introducing-bedrock-engineer
gawa
11
1.9k
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
870
定理証明プラットフォーム lapisla.net
abap34
1
1.8k
技術を根付かせる / How to make technology take root
kubode
1
240
Formの複雑さに立ち向かう
bmthd
1
810
Amazon ECS とマイクロサービスから考えるシステム構成
hiyanger
2
520
GoとPHPのインターフェイスの違い
shimabox
2
170
Featured
See All Featured
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
The Language of Interfaces
destraynor
156
24k
How to train your dragon (web standard)
notwaldorf
91
5.8k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
29
2.2k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Into the Great Unknown - MozCon
thekraken
35
1.6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.5k
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で色々な言語を使いたい場合