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
ScalaでgRPC
Search
kenji yoshida
March 18, 2018
Programming
0
1.7k
ScalaでgRPC
ScalaでScalaPBを使ってgRPCをする話。
ScalaMatsuri 2018のアンカンファレンスでの発表
kenji yoshida
March 18, 2018
Tweet
Share
More Decks by kenji yoshida
See All by kenji yoshida
sbt 2
xuwei_k
0
360
数十万行のプロジェクトを Scala 2から3に完全移行した
xuwei_k
0
1.5k
Scalaプロジェクトの ビルド速度改善
xuwei_k
0
510
Scala-Matsuri-2023.pdf
xuwei_k
0
1.6k
WartremoverのScala 3対応
xuwei_k
0
200
アルプでのScala 3移⾏
xuwei_k
1
1.7k
scalaprops
xuwei_k
0
150
Other Decks in Programming
See All in Programming
PostgreSQL を使った快適な go test 環境を求めて
otakakot
0
370
メタプログラミングで実現する「コードを仕様にする」仕組み/nikkei-tech-talk43
nikkei_engineer_recruiting
0
140
Claude Codeセッション現状確認 2026福岡 / fukuoka-aicoding-00-beacon
monochromegane
3
350
AI巻き込み型コードレビューのススメ
nealle
2
2.4k
20260228_JAWS_Beginner_Kansai
takuyay0ne
5
410
New in Go 1.26 Implementing go fix in product development
sunecosuri
0
100
朝日新聞のデジタル版を支えるGoバックエンド ー価値ある情報をいち早く確実にお届けするために
junkiishida
1
290
AI主導でFastAPIのWebサービスを作るときに 人間が構造化すべき境界線
okajun35
0
430
AIに仕事を丸投げしたら、本当に楽になれるのか
dip_tech
PRO
0
170
Geminiの機能を調べ尽くしてみた
naruyoshimi
0
190
CSC307 Lecture 13
javiergs
PRO
0
310
go directiveを最新にしすぎないで欲しい話──あるいは、Go 1.26からgo mod initで作られるgo directiveの値が変わる話 / Go 1.26 リリースパーティ
arthur1
2
410
Featured
See All Featured
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
59
50k
エンジニアに許された特別な時間の終わり
watany
106
240k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.3k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
220
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
200
BBQ
matthewcrist
89
10k
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
110
Ruling the World: When Life Gets Gamed
codingconduct
0
160
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.2k
The SEO Collaboration Effect
kristinabergwall1
0
380
Design in an AI World
tapps
0
160
Optimizing for Happiness
mojombo
379
71k
Transcript
Scala でgRPC ScalaMatsuri 2018 1 / 36
twitter @xuwei_k github @xuwei-k blog https://xuwei-k.hatenablog.com 2 / 36
Scala 忍者 未来から送られてきた関数型プログラミングロボット 3 / 36
2017 年のOSS 活動 出したpull request 825 merge されたpull request 750
4520 contributions 4 / 36
gRPC 公式サイト grpc.io 5 / 36
2015 年2 月にGoogle が 発表したhttp2 を使った RPC フレームワーク 6 /
36
google 内部ではstubby という名前で ずっと内部で使われているらしい stubby をOSS として作り直したのがgRPC 7 / 36
gRPC デフォルトでは protocol buffers が使われる 他のシリアライズ方式に差し替えることも可能 だがそれほど使われていない? 8 / 36
公式対応言語 C++, Java, Python, Go, Ruby, C#, Node.js, Android, Objective-C,
PHP PHP はクライアントのみ 9 / 36
gRPC とは 公式では Scala は対応していない protocol buffers 自体に plugin があるの
で、それでコード生成をして対応できる 内部的には grpc-java を使っている grpc-java の実装はnetty 4.1 を使っている 10 / 36
protocol buffers の plugin protoc プラグインの書き方 by @yugui さん yugui
さんは元google でgrpc-gateway なども作っておりとても詳しい 11 / 36
Protocol Buffers は遅いのか 同僚 遅いかどうかの話じゃなく protocol buffers の特徴をうまく説明している? のでオススメ 12
/ 36
https://xuwei-k.github.io/scala- protobuf-docs/grpc https://github.com/xuwei-k/grpc-scala- sample 13 / 36
Scala での使い方 14 / 36
https://github.com/scalapb/ScalaPB Scala での protocol buffers のライブラリ gRPC にも対応している @xuwei-k が対応させました
15 / 36
たぶん3 年連続くらいで2 位 16 / 36
project/plugins.sbt addSbtPlugin("com.thesamet" % "sbt-protoc" % "0.99.18") libraryDependencies += "com.thesamet.scalapb" %%
"compilerplugin" % "0.7.1" 17 / 36
build.sbt import scalapb.compiler.Version.{ scalapbVersion, grpcJavaVersion } PB.targets in Compile ++=
Seq( scalapb.gen() -> (sourceManaged in Compile).value ) libraryDependencies ++= Seq( "io.grpc" % "grpc-netty" % grpcJavaVersion, "com.thesamet.scalapb" %% "scalapb-runtime-grpc" % scalapbVersion ) 18 / 36
service の定義 https://github.com/grpc/grpc- java/blob/v1.10.0/examples/src/main/proto/helloworld.proto message HelloRequest { string name =
1; } message HelloReply { string message = 1; } service Greeter { rpc SayHello (HelloRequest) returns (HelloReply) {} } 19 / 36
Server の実装 https://github.com/xuwei-k/grpc-scala-sample/blob/a5d4fb9a952/grpc- scala/src/main/scala/io/grpc/examples/helloworld/HelloWorldServer.scala#L80- L81 class GreeterImpl extends GreeterGrpc.Greeter {
override def sayHello(req: HelloRequest): Future[HelloReply] val reply = HelloReply(message = "Hello " + req.name) Future.successful(reply) } } 20 / 36
protobuf でリクエスト、レスポンス、サービスを 定義 リクエストを引数にとって、Future[ レスポンス] を返すメソッドを実装 21 / 36
Client リクエストやレスポンスのパーサー的なものは実装の 必要ない https://github.com/xuwei-k/grpc-scala- sample/blob/a5d4fb9a95/grpc- scala/src/main/scala/io/grpc/examples/helloworld/HelloWorldClient. 22 / 36
client のインスタンスの生成 val channel = ManagedChannelBuilder .forAddress(host, port) .build() val
blockingStub = GreeterGrpc.blockingStub(channel) https://github.com/xuwei-k/grpc-scala- sample/blob/a5d4fb9a952c3e895e791b13786f8eb1681b6f65/grpc- scala/src/main/scala/io/grpc/examples/helloworld/HelloWorldClient.scala#L75-L77 23 / 36
リクエストを作成して渡す val request = HelloRequest(name) val response = blockingStub.sayHello(request) 24
/ 36
Java との違い unary の場合は、StreamObserver は使用せずに、 scala のFuture を返すという規約にした その他の場合はJava と似たような感じで
StreamObserver を使用 つまり必要以上に関数型な感じにはあえてしなかった 25 / 36
リクエストとレスポンスがそれぞれstream か否か? で4 種類ある Unary Server Streaming Client Streaming Bidirectional
Streaming 26 / 36
/* unary */ rpc hello(Req) returns (Res){} /* server streaming
*/ rpc hello(Req) returns (stream Res){} /* client streaming */ rpc hello(stream Req) returns (Res){} /* bidirectional streaming */ rpc hello(stream Req) returns (stream Res){} 27 / 36
4 種類の実装のサンプル 28 / 36
Unary リクエストを1 つ送るとレスポンス1 つ返る def hello(req: Req): Future[Res] = {
// req: Req を使って Future[Res] を返す処理 } 29 / 36
Server Streaming リクエストを1 つ送るとレスポンスがゼロ個以上の複数 返る def hello(request: Req, observer: StreamObserver[Res]):
Unit = { // observer.onNext を0 回以上複数回呼ぶ } 30 / 36
Client Streaming リクエストを複数送ると、レスポンスが返る def hello(observer: StreamObserver[Res]) = new StreamObserver[Req] {
// onNext などを実装 } 31 / 36
Bidirectional Streaming リクエストを複数送ると、レスポンスが複数返る(?) def hello(observer: StreamObserver[Res]) = new StreamObserver[Req] {
// onNext などを実装 } 32 / 36
無理してstream 使わずに、どうしても必要でない限り unary だけで良い気がする ( 個人の感想) 33 / 36
server streaming 使うと、たしかにサーバーからの push が簡単にかけそう・・・? 34 / 36
bidirectional はエラー処理や状態を考えると、 かえって色々自由すぎて面倒・・・? 誰か良いユースケースがあったら逆に教えて欲しい 35 / 36
質問コーナーや、ライブコーディング 36 / 36