このエントリでは、まずBaaSの現状、とりわけロックインについての課題点を説明し、私たちの新しいBaaSであるvte.cxのアプローチについて、提供する立場から解説する。
スケールしないBaaSの現状
とにかくBaaSは運用が大変なのだという。
BaaSなのに、人が手厚くサポートしないと何も作ってもらえないか、すぐに見放されることが多いとのこと。
また、放っておくと乱暴なユーザによってリソースが食いつぶされる事案がよく発生するらしい。 その場合、お客様に直接言って原因となっているクエリを改修してもらうようお願いすることもあるとか。
当初の理想からかけ離れた事態に陥っているのが今のBaaSの現状だと思う。
BaaSは既にバックエンドそのものが提供されているのでバックエンドを開発する必要性がない。 その分、工数が削減されるので、少ない人的リソースでサービスを素早く構築できる可能性が広がる。
また、クラウドの特性を生かして自動化できればスケールメリットも生まれる。
ところが、いちいち人が客対しないとだめな現状では、このようなBaaSのメリットが生まれないし、請負開発と実質的に同じことである。
むしろ、BaaSでは制約がある分、妥協や苦痛を強いられるので、それだったらBaaSを使わないで最初から自分たちでサーバ立てる方がましではないか、となる。
逆ベンダーロックインの恐怖
また私はあるBaaSベンダーに聞いた。
「どうして自動化してスケールする仕組みにしないの？」
衝撃的な答えが返ってきた。
「曲がりなりにも既存のお客様が利用されているので機能改善ができないのです。」
実は既存のシステムがあるせいで進むことも止めることもできないという硬直した状態に陥っていたのである。
この状態に名前をつけるとしたら「逆ベンダーロックイン」というところか。
ベンダーに囲い込まれて身動きが取れないユーザの状態をベンダーロックインというが、逆ベンダーロックインは既存ユーザに囲い込まれて身動きが取れないベンダーの状態をいう。
ユーザはロックインが怖くて踏み込めない悩みがあるのではと思いきや、ベンダーもユーザのロックインで悩んでいたというオチ。
反吐が出そうなお仕着せAPIと押し付け仕様を強要し、お互いに辛みを抱えながら何も改善できない状況が永遠に続く。
なんという痛々しい状態だろう。
フロントエンジニアを救うはずだったBaaSはミイラ取りがミイラになっている。
BaaS界隈はこのようにダメダメ感満載の現状なのである。
その彼に「弊社もBaaSに参入しますのでよろしく」といったところ、
「それはご愁傷様です」と返された。まじかよ。(><;)
vte.cxのアプローチ
結論からいうと、vte.cxであれば、ベンダーロックインも逆ベンダーロックインも発生しないので心配ない。
vte.cxは、これまでの「バックエンドAPIを提供することだけに特化している」というBaaSの概念を覆す、極めて自由度の高いBaaSである。
その理由は、そもそもAPIやSDKライブラリを提供しないからだ。つまり、SDKがなくても使える。それがvte.cxのよいところ。
なので、よくBaaSのデメリットとしていわれる「ユーザはただBaaSが提供するWebAPIやクライアントライブラリを使用するのみであり自由度はありません」といった説明はvte.cxに限っては当てはまらない。
「バックエンドAPIを提供する」ための基盤を提供するのがvte.cxの役目で、あるのは規約だけ。サーバの導入・設定、テーブルの設計、O/Rマッピング等の構築は一切必要ない。
また、マイクロサービス的にプラグインで拡張していくことが可能なため、よほどのことがない限り、別途バックエンドの構築が必要になるようなことはない。
リソースとデータモデル
他のBaaSでは、例えば、ユーザ管理用API、ACL管理用API、データ管理用API、ファイル管理用API・・・といったように、それぞれ別のAPIを用意していることが多い。
このように、BaaSのAPIには設計した人独自の感性による「お勝手API」が定義されている。そこにはデータモデルが存在せず、ひどく散らかっている印象がある。 それに、与えられたAPIの範疇でしか使えないし、そもそも用意されているAPIの機能が貧弱だ。
APIではなくて管理画面を使うものもあるが、管理画面を操作する≠便利ということがわかっていない。
APIにせよ画面にせよ、こういった固定的でお仕着せなのがロックインの元凶だと私は思っている。
そのBaaSを使うということは、永久にお勝手APIに付き合わないといけない。
よほど洗練されたAPIじゃないとお近づきになりたくないと思うのは私だけではないだろう。
一方のvte.cxは「バックエンドAPIを提供する」ための基盤であり規約である。
その規約の一つがリソースとデータモデルになる。
重要なのはAPIではなくリソース。これは、RESTの原点でもあったはずだ。
リソースというのはデータの集合であり、RESTによる操作でJSONになったりXMLになったりMessagePackになったりする。
ACL、プロパティファイル、HTMLやCSS、JavaScriptや画像などもすべて同じようにリソースとして扱われる。
また、リソースはすべてがデータツリーの中で表現される。
データツリーは、Unixファイルシステムのディレクトリ構造と同じと思えばよい。直感的で非常にわかりやすい構造だ。
vte.cxではACLも設定ファイルも単なるリソースの一つであり、他のリソースと同様、RESTで操作できる。
余談ではあるが、Open API Initiativeが結成されて、「RESTful APIのためのWSDLとも言うべき、RESTful APIのインターフェイスを記述する」なんて記事が出た。 我々はいつまでAPIの標準化に振り回されつづけるのかという残念な気持になるが、そもそも問題点を見誤っていないか？
JSONでAPIを記述できるSwaggerをベースにしており、「APIのオープンな相互運用性を促進すると同時に可能性を拡大するためのもの」とのことである。
WSDLでやろうとして失敗したことを単純にJSONでやるだけで成功するのか？私はそうは思わない。
前述したように、お仕着せお勝手APIをSwaggerで晒したところで、「オープンな相互運用性を促進できる」ほど甘くないことは明らかだろう。
また、WebAPIが単なるRPCではうまくいかないことはCORBA IIOP、SOAP-RPC等の歴史が証明しているし、開発者はこのことにもっと注意を払うべきである。
このあたりについては、過去の記事「IsomorphicとAPIファーストについて」なども読んでもらいたい。
ただしフロントエンドエンジニアの責務は大きくなる
フロントエンドエンジニアは、バックエンドの処理を考えないでフロントエンド駆動で開発するが、サーバで必要なものはAPIを参照しながら開発していく。
しかし、API一覧のようなものがないと戸惑うフロントエンドエンジニアは意外に多いと思う。これについては、過去の記事「RESTとJSON、スキーマ定義について思うところ」にも書いた。
vte.cxでは、リソースを操作するAPIを規約に則って実装するのはユーザの責務である。
つまり、APIを作るのは YOU 。
とはいっても、サーバサイドのAPIが既にあることが前提で開発することが多いフロントエンジニアに、いきなりAPIを作れといって戸惑うのも当然かもしれない。
これは実質的にサーバサイドを作らされているのと同じ意味であり大きな負担であることは間違いない。
しかし、vte.cxのAPIはURIとスキーマだけ設定すればいいため、ゼロからサーバサイドを立てるよりはるかに楽なはずである。
スキーマは画面の項目をそのままスキーマの項目に落としていけばいいし、RDBのテーブル設計に伴う正規化などは一切考える必要はない。
稀にスキーマレスを主張する人がいるが、ログ収集などは別として業務アプリケーションではスキーマをしっかりと設計するのは常識である。
BaaSはスキーマレスのMongoDBを使っているところが多いのでスキーマ設計ができないものが多いのだが、これをしっかりやらないと後でイタい目にあうことはココとか、ココとか見れば明らかである。
最後に
ここまで、既存BaaSの問題点とvte.cxのアプローチについて述べてきたが、具体的なAPIの実装方法についてはQiitaの記事にまとめていくつもりなのでぜひ読んでもらいたい。
また、12/16(水)にセミナーをやるので、興味のある方はぜひ参加してください。
