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
数十万行のプロジェクトを Scala 2から3に完全移行した
xuwei_k
0
1.5k
Scalaプロジェクトの ビルド速度改善
xuwei_k
0
400
Scala-Matsuri-2023.pdf
xuwei_k
0
1.5k
WartremoverのScala 3対応
xuwei_k
0
180
アルプでのScala 3移⾏
xuwei_k
1
1.6k
scalaprops
xuwei_k
0
140
Other Decks in Programming
See All in Programming
ライブ配信サービスの インフラのジレンマ -マルチクラウドに至ったワケ-
mirrativ
2
270
Azure SRE Agentで運用は楽になるのか?
kkamegawa
0
700
モバイルアプリからWebへの横展開を加速した話_Claude_Code_実践術.pdf
kazuyasakamoto
0
290
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
250
Processing Gem ベースの、2D レトロゲームエンジンの開発
tokujiros
2
110
レガシープロジェクトで最大限AIの恩恵を受けられるようClaude Codeを利用する
tk1351
4
1.5k
AIレビュアーをスケールさせるには / Scaling AI Reviewers
technuma
2
230
Microsoft Orleans, Daprのアクターモデルを使い効率的に開発、デプロイを行うためのSekibanの試行錯誤 / Sekiban: Exploring Efficient Development and Deployment with Microsoft Orleans and Dapr Actor Models
tomohisa
0
220
MCPで実現するAIエージェント駆動のNext.jsアプリデバッグ手法
nyatinte
7
990
パスタの技術
yusukebe
1
540
Understanding Ruby Grammar Through Conflicts
yui_knk
1
190
Infer入門
riru
4
1.6k
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
The Art of Programming - Codeland 2020
erikaheidi
55
13k
Designing for Performance
lara
610
69k
The Language of Interfaces
destraynor
160
25k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Git: the NoSQL Database
bkeepers
PRO
431
65k
Designing Experiences People Love
moore
142
24k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
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