「知らなかった、を聞く」カンファレンス Builderscon 2017 で発表してきました。
お題は、「フロントエンドエンジニアが主役のBaaSを作った話」です。
まずはじめに、聞きに来ていただいた方、質問をしてくれた方、twitterで呟いてくれた方に御礼申し上げます。大変嬉しゅうございました。 Togetter
資料は、ここに上げています。
感想
当日はどんな内容をしゃべろうかいろいろ考えたのですが、聴衆受けするような流行りの話ではなく、むしろそれを否定し、独自の考え方と経緯などをすべてをさらけ出してみようと思って臨みました。結果は案の定、玉砕に近い感じになりました。
でも、それでよかったと思っています。いや、逆によくこのテーマで人が集まったものだと驚いているくらいです。辛抱して最後まで聞いていただき感謝しております。
私達は何年もかけて、reflexworks/vte.cxというフレームワークやサービスを開発しています。
個別ではなんとなく反応はわかるのですが、buildersconのような大きなイベントで、目の肥えたエンジニアの方々がどのような反応をするのか全くわからなかったし、今回、質問やtwitterなどでそれが知れて大変よかったと思っています。
補足
twitterの中で重要だなと思った点、うまく答えられなかったものについて補足します。これはよくぞ言ってくれたという感じです。フロントエンドに限らず、式年遷宮的なアーキテクチャ重要だから、ベンダーロックインってその点で駄目なのよね。棄てられることというのはアーキテクチャの上でとても重要#buildersconC
— 最新JS本8/11発売 (@erukiti) 2017年8月5日
フロントエンドの技術は捨てる覚悟が必要で、私達は急激な変化にも常にキャッチアップしていけるように取り組んでいこうと考えています。vte.cxであればそれが可能です。
これは全くその通りです。これ「フロントエンジニアが API 定義できる」ということだけど、定義するための仕様が致命的に重要になる気がする。何らかの形で汎用性を持たせないと結局ロックインされるだけなので。 #builderscon #buildersconC
— チェシャ猫 (@y_taka_23) 2017年8月5日
感のいい方は、いくら規約で縛ったところで、API構造自体が独自仕様であればロックインを免れないとすぐに気づきます。
vte.cxにはAPI設計ルールに独自仕様があり、そこを汎用的にしなければロックインは免れないとの指摘です。確かに、このXML/JSON構造自体が独自仕様ではあるわなー#buildersconC
— 最新JS本8/11発売 (@erukiti) 2017年8月5日
ただ、これについては楽観的な見方をしています。
というのは、vte.cxの独自仕様で作ったAPIであったとしても、I/Fは単なるJSONなのですから、それを元にAPIを作ることは容易いことです。その気になれば、vte.cxのスキーマ定義を捨てて、全く別のサーバアーキテクチャでAPIを作ることはできます。
その際に、クライアントコードに設定情報などが残っていると移植作業は大変になるでしょう。
vte.cxでは、設定情報をソースコードは分離しているので、クライアントコードはそのままで、いつでも移行可能である点が強調したかったことです。
あと、swaggerなどのAPIの標準化の対応は？という質問については概ね以下のツイートのとおりです。
質問者からは意図が伝わらなかったということでしたので、もう少し補足するとすれば、私達の標準化にこだわりがないというスタンスということになるなるかと思います。vte.cxにとってのAPIは、アプリケーション内部でのフロントエンドとバックエンドの通信が主目的なので、swaggerとかそういうのを採用するメリットがマーケティング的に薄いって話なわけですね。#buildersconC https://t.co/m9y5dks92J
— 最新JS本8/11発売 (@erukiti) 2017年8月5日
実はこのフレームワークの歴史は古く、コア部分を作ったのが2006年頃で、当時はXML/WSDLでI/F記述することが推奨されていました。これは今のswaggerみたいなものです。
私達は標準だからといってWSDLに対応することはありませんでしたが、今ではその判断は正しかったと思っています。
swaggerが標準だと今はいわれますが、今後５年後、１０年後どうなっているかわかりません。JSONSchemaを採用しないのも同じ理由です。当時ではXMLSchemaやRelaxNGなどがありました。
独自仕様か（その時の）標準仕様か、判断は難しいですが、（その時の）標準仕様っぽいものに対応した場合の一時的なメリットよりも技術的負債化を恐れるべきというのが私達のスタンスです。つまり、常に変わってもいいものと、ずっと変わらないものがあって、フロントエンド技術は常に変わることを許容しますが、I/Fやスキーマというのはずっとかわらないものとして扱うべきという考え方です。
おっしゃるように、３番目が特に重要です。「こだわった点。バックエンドの複雑さを隠蔽、API 設計に集中できる、ローカルの開発環境や CI/CD 環境を提供」個人的に三つ目は非常に重要なメリットだと思う。 #builderscon #buildersconc
— チェシャ猫 (@y_taka_23) 2017年8月5日
SPA + serverless (API gateway + Lambda) と、vte.cx のアプローチ、あまり変わりがないように見えるという意見もありましたが、この３番目はサーバレスでは実現できない重要な点になります。
ということで、楽しい機会を与えていただいた、builderscon の運営の皆様、聞きに来ていただいた方、ご意見をいただいた方、重ねて御礼申し上げます。大変ありがとうございました！
