※再UP MagicOnionを利用した場合と利用しない場合の違いを簡単にまとめてみました。 サンプルコードはこちら https://github.com/gsino/MagicOnionSample

1. Using or not using
MagicOnion
MagicOnionを使うと場合と使わない場合

2. 自己紹介
- 篠原吾一 (@gsino_)
- C#でゲーム作っています
- 前職ではMagicOnionを利用したスマホゲームを
開発していました

3. 今回のおはなし
MagicOnionとは
=> C#でgRPCを使用するためのフレームワーク
ただしMagicOnionを使用しないでもC#でgRPCの
サーバーを実装することは可能
両者を比較して、特徴を捉えてみます

4. MagicOnionによるgRPC
- C#(.NET) インターフェースがIDL
- シリアライザはMessagePack for C#
- StreamingHubなどの独自機能
- 引数/戻り値の制限が緩い
（プリミティブ型を使用可能、複数の引数を定義可能）
- サーバー/クライアントともにC#(などの.NET言
語)でないとならない

5. DEMO

6. MagicOnionを使用しないgRPC
- .protoファイルがIDL
- シリアライザはProtocolBuffer
- Grpc.Toolsでクライアント/サーバーのベースク
ラスを自動生成
- 言語非依存

7. DEMO

8. 番外編 HTTP/1アクセスしたい
javascriptなどからはgRPCは使用できないが、代替手段は用意されている。
MagicOnionの場合
=> MagicOnion.HttpGateway
HTTP/1アクセスからgRCPを通さずにメソッドを呼び出し(Unaryのみ)
Swagger出力もしてくれるので、APIの確認に良い
素gRPCの場合
=> gRPC-Web
リバースプロキシを用いてHTTP/1 <=>gRPCを変換
2つ実装があり、片方はServerStreamingに対応

9. 表にしてみた
MagicOnion 素gRPC
IDL C#(.NET) インターフェー
ス
.protoファイル
シリアライザ MessagePack for C# ProtocolBuffer
言語 C# (F#/VB など.NET言語) 大体の言語
クライアント サーバー実装と同一イン
ターフェースのクライアン
ト自動生成(実行時or事前)
サーバー実装とは別インター
フェースのクライアント事前生成
引数/戻り値 複数可、プリミティブ可 複数不可、プリミティブ不可
Http/1アクセス MagicOnion.HttpGateway gRPC-Web

10. どのように使い分けるべきか
MagicOnionを使いたいケース
サーバー/クライアントがともに.NET
& やり取りの方法が自前でコントロールできる
=> ゲームやアプリのクライアント-サーバー通信
素gRPCを使いたいケース
サーバー/クライアントに.NET以外が含まれる
or システム外部とgRPCでやり取りをしたい
=> 外部から広くアクセスしてもらうシステム
=> すでに実装すべき.protoが規定されている

11. MagicOnionは使いたいけど、社内のツールの都合で
一部APIは素のgRPCが必要なので無理かな・・・
(´・ω・｀)

12. 実は両立できます
一つのgRPCサーバーにMagicOnionと素gRPCを同
居させることは可能

13. DEMO

14. まとめ
MagicOnionと素gRPCで得意なところは異なる
うまく使い分けよう
素gRPCを使いたい要件があっても、MagicOnion
と同居できるので、あきらめてはいけない！

15. ありがとうございました