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
340
数十万行のプロジェクトを Scala 2から3に完全移行した
xuwei_k
0
1.5k
Scalaプロジェクトの ビルド速度改善
xuwei_k
0
490
Scala-Matsuri-2023.pdf
xuwei_k
0
1.6k
WartremoverのScala 3対応
xuwei_k
0
190
アルプでのScala 3移⾏
xuwei_k
1
1.7k
scalaprops
xuwei_k
0
150
Other Decks in Programming
See All in Programming
高速開発のためのコード整理術
sutetotanuki
1
350
Graviton と Nitro と私
maroon1st
0
180
AtCoder Conference 2025
shindannin
0
1k
CSC307 Lecture 02
javiergs
PRO
1
770
フロントエンド開発の勘所 -複数事業を経験して見えた判断軸の違い-
heimusu
7
2.7k
なるべく楽してバックエンドに型をつけたい!(楽とは言ってない)
hibiki_cube
0
130
AI Agent の開発と運用を支える Durable Execution #AgentsInProd
izumin5210
7
2.2k
Fluid Templating in TYPO3 14
s2b
0
120
CSC307 Lecture 04
javiergs
PRO
0
650
Patterns of Patterns
denyspoltorak
0
1.3k
副作用をどこに置くか問題:オブジェクト指向で整理する設計判断ツリー
koxya
1
560
Apache Iceberg V3 and migration to V3
tomtanaka
0
110
Featured
See All Featured
The SEO identity crisis: Don't let AI make you average
varn
0
57
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
83
BBQ
matthewcrist
89
10k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
1
1.4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
630
Statistics for Hackers
jakevdp
799
230k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
1.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Music & Morning Musume
bryan
47
7.1k
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