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.4k
Scalaプロジェクトの ビルド速度改善
xuwei_k
0
370
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
Rubyでやりたい駆動開発 / Ruby driven development
chobishiba
1
730
Flutterで備える!Accessibility Nutrition Labels完全ガイド
yuukiw00w
0
160
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
4k
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
1
430
Hack Claude Code with Claude Code
choplin
4
2.2k
The Modern View Layer Rails Deserves: A Vision For 2025 And Beyond @ RailsConf 2025, Philadelphia, PA
marcoroth
2
400
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
130
dbt民主化とLLMによる開発ブースト ~ AI Readyな分析サイクルを目指して ~
yoshyum
3
1k
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
170
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
230
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
91
30k
地方に住むエンジニアの残酷な現実とキャリア論
ichimichi
5
1.6k
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Code Review Best Practice
trishagee
69
19k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Agile that works and the tools we love
rasmusluckow
329
21k
Music & Morning Musume
bryan
46
6.6k
Git: the NoSQL Database
bkeepers
PRO
430
65k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Navigating Team Friction
lara
187
15k
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