SUGOSとは何ですかという問いに対して"A high-level RPC framework to make remote controlling super easy."と答えると次に高確率でやってくるのがこの質問
"What is the difference from gRPC?"
gRPCはGoogleが出しているRPCフレームワーク。gRPCの公式ガイドを見ると
In gRPC a client application can directly call methods on a server application on a different machine as if it was a local object, making it easier for you to create distributed applications and services
とか書いてある。コンセプトで言えばもろ被り。Google様が出してるしGitHub星いっぱいついてるし今更うちらが似たようなの作る必要なくね、という気もする。でも必要だったのだ。SUGOSが。
SUGOSはラピッドプロトタイピングを繰り返しているうちに生まれた。ウチの会社でIoTやらクラウドロボティクス的なことやりたいんだけど何をどう作ればいいかわかんないからDemoドリブンでブラウザ上のUIからなんか色々操れたりするやつをいっぱい作ってちょといわれていろんなデバイスのSDKをこねくり回して繋いでごにょごにょ改造しているうちに思った。 KinectとかpepperとかRapiroとかHITOEとかardupilotとかいろんなSDKが全部ブラウザから同じように呼べればいいのに。呼べるようにするか。よし作ろう。関数定義を動的に共有して勝手にブラウザ側のJS関数として定義し直すような仕組みを。
SUGOSは関数定義を動的に共有してリモートから呼べるようにする仕組みだ。なので事前にインターフェースを決める必要がない。適当に試しながらあれこれ変えるのに向いている。
一方、gRPCは先にインターフェースを定義する必要がある。.protoファイルに記したシグネチャから各言語のファイルを自動生成して、それを実装するという形だ。この辺りはTwitterの出しているFinagleも同じだったはず。
まずインターフェースを決める、というのはもちろん「正しい」やり方だ。
だが合わなかった。何が正解かは誰もしらず頻繁に変更が入り泥臭い試行錯誤を強いられる現場においては空回りする理想論でしかなかった。
変更が入るからこそ先にインターフェースを決めるのだろうという意見もあったが、そのインターフェースを決める作業自体が難しい。最低限の約束だけ決めてそれを保証するアプローチよりも適当に動かしながら最終的にe2eで動いたものを提供する形の方がライフサイクルがはるかに速い。とりあえず大体でいいから動きゃいいんだよ。
そう思ってSocket.IOをwrapしJSON-RPCをリッチにして双方向にやり取りできる仕組みを作ってみたらSUGOSになった。
なお、SUGOSとgRPCの比較表は以下
| SUGOS | gRPC | |
|---|---|---|
| データののシリアライズ | JSON文字列 | Protocol Buffer |
| 呼び出し構造 | クライアントが提供する関数を、Hubサーバを経由して別クライアントから呼び出す | サーバが提供した関数をクライアントから呼び出す |
| 関数の実装方法 | 関数を実装すると、自動的にインターフェースを解析して共有する | インターフェースファイル(.proto)を先に定義し、そこから雛形を自動生成した後、中身を実装する |
| 対応言語 | JavaScript | C++ C# GO JAVA PYTHON、等 |
| ブラウザ上での実行 | 可能 | （今のところは）不可能 |
| 想定システム | ユーザーインターフェースを備えた遠隔アプリケーション | 言語やネットワークをまたいだ分散処理 |