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.6k
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
110
Scalaプロジェクトの ビルド速度改善
xuwei_k
0
200
Scala-Matsuri-2023.pdf
xuwei_k
0
1.4k
WartremoverのScala 3対応
xuwei_k
0
160
アルプでのScala 3移⾏
xuwei_k
1
1.5k
scalaprops
xuwei_k
0
130
Other Decks in Programming
See All in Programming
社内活動の取り組み紹介 ~ スリーシェイクでこんな取り組みしてます ~
bells17
0
400
型のインスタンス化は非常に深く、無限である可能性があります。
kimitashoichi
0
180
Amazon Aurora Serverless v2のアプデと、Amazon Aurora PostgreSQL Limitless DatabaseのGAについて
satoshi256kbyte
0
110
第5回日本眼科AI学会総会_AIコンテスト_3位解法
neilsaw
0
150
17年周年のWebアプリケーションにTanStack Queryを導入する / Implementing TanStack Query in a 17th Anniversary Web Application
saitolume
0
230
Go の GC の不得意な部分を克服したい
taiyow
2
510
Cloudflare MCP ServerでClaude Desktop からWeb APIを構築
kutakutat
1
350
As an Engineers, let's build the CRM system via LINE Official Account 2.0
clonn
1
660
フロントエンドのディレクトリ構成どうしてる? Feature-Sliced Design 導入体験談
osakatechlab
8
3.9k
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
150
命名をリントする
chiroruxx
1
260
The rollercoaster of releasing an Android, iOS, and macOS app with Kotlin Multiplatform | droidcon Italy
prof18
0
150
Featured
See All Featured
Designing Experiences People Love
moore
138
23k
Thoughts on Productivity
jonyablonski
67
4.3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Code Review Best Practice
trishagee
65
17k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
75
The Invisible Side of Design
smashingmag
298
50k
It's Worth the Effort
3n
183
27k
Automating Front-end Workflow
addyosmani
1366
200k
The Pragmatic Product Professional
lauravandoore
32
6.3k
The Cult of Friendly URLs
andyhume
78
6.1k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
900
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