日曜日, 8月 06, 2017

Builderscon 2017で発表してきた このエントリーを含むはてなブックマーク


「知らなかった、を聞く」カンファレンス Builderscon 2017 で発表してきました。
お題は、「フロントエンドエンジニアが主役のBaaSを作った話」です。
まずはじめに、聞きに来ていただいた方、質問をしてくれた方、twitterで呟いてくれた方に御礼申し上げます。大変嬉しゅうございました。 Togetter




資料は、ここに上げています。

感想

当日はどんな内容をしゃべろうかいろいろ考えたのですが、聴衆受けするような流行りの話ではなく、むしろそれを否定し、独自の考え方と経緯などをすべてをさらけ出してみようと思って臨みました。

結果は案の定、玉砕に近い感じになりました。
でも、それでよかったと思っています。いや、逆によくこのテーマで人が集まったものだと驚いているくらいです。辛抱して最後まで聞いていただき感謝しております。
私達は何年もかけて、reflexworks/vte.cxというフレームワークやサービスを開発しています。
個別ではなんとなく反応はわかるのですが、buildersconのような大きなイベントで、目の肥えたエンジニアの方々がどのような反応をするのか全くわからなかったし、今回、質問やtwitterなどでそれが知れて大変よかったと思っています。

補足

twitterの中で重要だなと思った点、うまく答えられなかったものについて補足します。
これはよくぞ言ってくれたという感じです。
フロントエンドの技術は捨てる覚悟が必要で、私達は急激な変化にも常にキャッチアップしていけるように取り組んでいこうと考えています。vte.cxであればそれが可能です。
これは全くその通りです。
感のいい方は、いくら規約で縛ったところで、API構造自体が独自仕様であればロックインを免れないとすぐに気づきます。
vte.cxにはAPI設計ルールに独自仕様があり、そこを汎用的にしなければロックインは免れないとの指摘です。
ただ、これについては楽観的な見方をしています。
というのは、vte.cxの独自仕様で作ったAPIであったとしても、I/Fは単なるJSONなのですから、それを元にAPIを作ることは容易いことです。その気になれば、vte.cxのスキーマ定義を捨てて、全く別のサーバアーキテクチャでAPIを作ることはできます。
その際に、クライアントコードに設定情報などが残っていると移植作業は大変になるでしょう。
vte.cxでは、設定情報をソースコードは分離しているので、クライアントコードはそのままで、いつでも移行可能である点が強調したかったことです。

あと、swaggerなどのAPIの標準化の対応は?という質問については概ね以下のツイートのとおりです。 質問者からは意図が伝わらなかったということでしたので、もう少し補足するとすれば、私達の標準化にこだわりがないというスタンスということになるなるかと思います。

実はこのフレームワークの歴史は古く、コア部分を作ったのが2006年頃で、当時はXML/WSDLでI/F記述することが推奨されていました。これは今のswaggerみたいなものです。
私達は標準だからといってWSDLに対応することはありませんでしたが、今ではその判断は正しかったと思っています。
swaggerが標準だと今はいわれますが、今後5年後、10年後どうなっているかわかりません。JSONSchemaを採用しないのも同じ理由です。当時ではXMLSchemaやRelaxNGなどがありました。
独自仕様か(その時の)標準仕様か、判断は難しいですが、(その時の)標準仕様っぽいものに対応した場合の一時的なメリットよりも技術的負債化を恐れるべきというのが私達のスタンスです。つまり、常に変わってもいいものと、ずっと変わらないものがあって、フロントエンド技術は常に変わることを許容しますが、I/Fやスキーマというのはずっとかわらないものとして扱うべきという考え方です。 おっしゃるように、3番目が特に重要です。
SPA + serverless (API gateway + Lambda) と、vte.cx のアプローチ、あまり変わりがないように見えるという意見もありましたが、この3番目はサーバレスでは実現できない重要な点になります。

ということで、楽しい機会を与えていただいた、builderscon の運営の皆様、聞きに来ていただいた方、ご意見をいただいた方、重ねて御礼申し上げます。大変ありがとうございました!
 
© 2006-2015 Virtual Technology
当サイトではGoogle Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。