今回の目的
リアルタイム系BaaS各社の利点と欠点を分析します。どんなケースでどのBaaSを使用すると良いのかイメージを持ってもい、技術選定に幅を持たせましょう!
背景
BaaSと言ってもいろいろあってわからないですよね。「強力なのはわかるけど、大切なデータは自分で持っておきたいし、急に使えなくなったときに代わりを用意するのが大変だ」と思うかもしれません。
何ができて何ができないのかを正しく把握して、要所要所で時間を節約してより高いクオリティや新しい開発スタイルを模索したいものです。
そんな中で、「HTTPのAPIであればスケーリングも含めて手軽に構築できるけれども、WebSocketサーバとなるとちょっと場合によっては足踏みするなあ」という方を対象に、どんなときにどのリアルタイム系BaaSを選択すれば良いのか解説していこうと思います。
BaaSは大きく分けると
- 「HTTPのAPIを提供し、主に秒間リクエスト数で課金するBaaS」
- 「WebSocket/MQTTで同時コネクション数で課金するBaaS」
の2種類になります。今回は後者を「リアルタイム系BaaS」と名付けて解説します。
各社、料金体系やサポートする機能、そして注力しているジャンルなどに差があります。さらに、プログラミング言語と同様に、解決したい課題や想定するユーザーが微妙に異なります。共通部分と独自部分の区別を中心に、今後彼らがどのような進化を目論んでいるかの解説なども含めて進めていければと思います。
比較対象
Googleに買収されたナイスガイです。得意分野はWebですが、アプリやIoTもソツなくこなします。先日、福岡でGoogleの方が啓蒙活動をしていたのが記憶に新しいですね。
IoT特化型だけどWebもいけるタフなヤツです。IBMとの提携話など、手堅くやっているようです。
日本でのユーザが多く、ユーザビリティが抜群です。WebとNode.jsを組み合わせてアプリとしたクリエイティブユースが日本語圏で目立ちます。エンドユーザプログラミングを掲げているように、使い勝手にとことんこだわっているようです。
比較基準
それぞれの比較基準を、基本的に
- (JSベースの)APIデザイン
- 機能の便利さ
- ドキュメントの理解しやすさ
- サンプルの多さ
- コミュニティの充実度
と定めます。これらをベースに、特筆すべき点を最後に挙げていこうと思います。
分析
Firebase
APIのデザイン
無骨で、厳密さを感じさせます。北米でのバックエンドエンジニアの人件費高騰を背景に、開発をもっと楽にしようという力が働いたのか、エンジニア向けのインターフェースになっているように感じられます。
例えば、OAuth関数の実行時に画面遷移で手続きを行うか、新規ウィンドウで行うかだったり、WebSocketハンドシェイクのdisconnect時に何をするかだったり、細かにコントロールすることを意図したインターフェースになっています。
ここが好みの分かれるところであり、Firebaseが「ゆりかごから墓場まで面倒を見る」と強く考えていることの現れかもしれません。
もともと「打倒Dropbox」を掲げていたこともあり、「データをリアルタイムに共有するためのもの」というよりも先に「データを保存するためのもの」であり、付随的にdataが追加されたイベントを用意したように感じられます。その影響か、単純なデータを保存しないpub-subの関数は存在しません。その辺りからも「エンジニア向けDropbox」のような思想を感じさせます。
主観的には、APIはやはり無骨です。on関数がWebSocketハンドシェイク時に毎回呼ばれ、その際にデータのレンダリングを行うモデルかと思われますが、初めは意図しない挙動に戸惑ってしまいました。console.log関数でオブジェクトの内部を見ても、基本的には難読化されていて手がかりがつかめないケースもままあります。
しかし慣れてくると、隅々まで行き届いた厳密さが光る良いインターフェースだと思われます。
Firebase HostingというBitBalloonのような無料静的ファイルホスティングサービスがありますが、これもnpmを用いてインストールするため、エンジニア向けである雰囲気を感じます。
機能の便利さ
個人的に高評価だったのが、AngularFireなどのブラウザ面を推し進めているだけあって、ありとあらゆるWeb開発での要求に応えてくれるところです。
例えば管理画面で、データストアの中身を見る事ができます。その際にデータをクリックしてその場で書き換えることもできますし、その場で直感的に削除することもできます。MongoDBのような巨大な連想配列を直感的に操作できるのは、開発中のちょっとしたミスを苦もなく修正できて非常に助かりました。
また、前項でも触れましたがOAuthの設定が細かく可能であったり、データ量が多くなっても問題ない時間で検索をかけられるスケーラビリティであったりも素晴らしいです。
データのバックアップなどは手動でJSONをエクスポートすることができますし、Node.js SDKを用いて自前で定期的にデータを抽出するプログラムを書く事も容易かと思います。
一方で、アプリやIoTの開発は一応サポートしているけれども、メインではないような感じを受けます。
ドキュメントの理解しやすさ
機能が非常に多いため、やや冗長な印象を受けますが、それをなるべくわかりやすく教えようという工夫を感じられる洗練されたドキュメントです。
残念ながら日本語版は存在しないので、翻訳の苦労は存在します。
サンプルの多さ
Webに限定すれば3社の中では最もサンプルが多いかもしれません。記事件数などのパブリックデータも提供していたり、Webに関して積極的に取り組んでいる姿勢が見られます。
コミュニティの充実度
StackOverflowが非常に活発です。全ての質問を中の人がSOで回答しており、相当量のノウハウが英語で蓄積されています。
SQLとFirebaseQueryの変換だったり、様々な実例が紹介されていて、詰まった際はSOを見れば多くの場合解決します。
PubNub
APIのデザイン
基本的にデータのリアルタイム同期体験を全面に押し出しています。PubNubの名にもあるように、pubnub.publishとpubnub.subscribeでのデータの同期が全てのベースです。
付随して、history関数を用いて同期したデータの履歴を取得したりなどもできますが、基本的には同期に特化したインターフェースです。また、ユーザのボリュームがある層がIoT系なので、今後もそちらのユースケースに合わせた改善が成されていくことが予想されます。
機能の便利さ
なんといってもリアルタイムBaaSの中で最も動作可能なクライアントライブラリが多いのが魅力です。そしてその中でも組込みデバイスへの対応具合がしっかりしています。
- Microchip PIC32
- MPLAB Harmony PIC32
- Arduino
- Raspberry Pi
- Android Embedded
- mBed (ARM)
- Electric Imp
- Java Embedded
- Atmel SAMA5D3
- Kinoma Create
- TI CC3200 LaunchPad (Energia)
- TI MSP430 F5529 LaunchPad with CC3100 WiFi BoosterPack (Energia)
等の多彩なマイコン上でPubNubインターフェースの通信を用いることが出来ます。これによってWebとは比較にならない数のデバイス数を稼ぎ出しているのでしょうね。
必然的に組込みユーザのユーザビリティに特化しているので、WebSocketハンドシェイクの際のブロードキャストサーバが複数用意されていて耐障害性を強く意識していたり、他のデバイスのネットワークへの参加不参加を簡単に取得できるようにしていたり、IoTネットワークのために作り込んだ機能が多く存在します。
もちろんWebやアプリにも使用できる機能なので、IoT開発やデバイス間連携に用いることも可能です。
ドキュメントの理解しやすさ
例のごとく英語でのみ書かれています。やはり対応クライアントが膨大なので、ドキュメントは自動生成になっており、一般的なシンプルなドキュメント然としています。
サンプルの多さ
USE CASESのページでウェアラブル端末やタクシー配車サービスの例を提示していますが、実際に動くソースコードへのアクセスは、特に日本人には容易では無さそうです。
コミュニティの充実度
Knowledge Baseと言うページに掲示板があります。人気テーマは以下のようです。
やはり、IoTコミュニティ強し、と言った感じですね。
Milkcocoa
APIのデザイン
3社の中で最もシンプルで削ぎ落とされたインターフェースをしています。会社のビジョンである「エンドユーザプログラミング」をそのまま現したような平易で学習コストが皆無なインターフェースですね。
- データレンダリングの際のQuery
- 保存の際のpush
- 保存時の同期の際のon("push", cb)
- 単純な送信に便利なsend
- その同期のon("send", cb)
このように、覚えることがほとんどありません。デザイナーよりのインターフェースと言うか、空気のような体験を意図しているような感じがします。
基本的にできることはFirebaseよりも少ないですし、PubNubよりも対応デバイスは圧倒的に少ないですが、「思い立ったときに作る」という体験のデザインにおいては他2社を寄せ付けない手軽さを誇ります。
プログラミング言語のRubyやJavaScriptから感じられる、プログラミングの楽しさ・手軽さを求めるクリエイターに好まれているのも頷ける仕上がりになっています。
機能の便利さ
管理画面でのデータの閲覧やセキュリティ設定は可能です。ソーシャルログインはまだありませんが、Emailでの認証は可能です。
iOS/Androidクライアントは正式公開されていませんが、日本にいる開発チームと相談してサポート付きで実案件投入したりする事例はあるようです。
機能はシリコンバレーの2社より少ないですが、ユーザとの相互関係の中で価値を生み出す引き算の美学と言ったところでしょうか。
ドキュメントの理解しやすさ
APIが簡潔なので覚える事は少ないです。
サンプルの多さ
「milkcocoa サンプル」で検索すると、日本語でたくさんブログがヒットします。これが日本人向けと呼ばれる所以です。
コミュニティの充実度
ブログの量やサンプルの量からもわかりますが、潜在的な日本人ユーザが相当量存在するので、勉強会やハッカソンを通じた出会いも多いです。
Milkcocoa Google GroupやMilkcocoa facebook groupなどでのユーザ間交流も活発なので、詰まった際の問題解決や最新情報のチェックには最も困らないと思います。
まとめ
英語に堪能な方なら、Webやアプリ用途ではFirebaseが非常に強いです。また、IoTではPubNubに一日の長があります。しかし、日本語圏でのコミュニティや情報量、そして思い立ったらすぐに実装できてしまう学習コストの低さなどにおいてはMilkcocoaも興味深いです。
Node.jsアプリケーションと組み合わせて使用したり、アプリやセンサーと連携させて使用したり、工数や契約の手間が短縮されることによる恩恵は、利用者が増えるに従って今後より一層無視できない大きな流れとして目に見えてくることが予想されます。
アカウントデータや課金系への使用は如何にGoogleが後ろ盾にいたとしても躊躇されるかもしれませんが、まずは社内の業務効率化ツールやメディアアート、ハッカソンやコンテストでの高速開発、休日のIoT日曜大工など、様々なユースケースを妄想する楽しみ方から始めてみてはいかがでしょうか。