これ「フロントエンジニアが API 定義できる」ということだけど、定義するための仕様が致命的に重要になる気がする。何らかの形で汎用性を持たせないと結局ロックインされるだけなので。 #builderscon #buildersconC
2017-08-05 14:27:03github.com/reflexworks/vt… XML(やJSON)でこれを延々書くの、逆にダルい予感 #buildersconC
2017-08-05 14:28:07SPA + serverless (API gateway + Lambda) と、vte.cx のアプローチ、あまり代わりがないように見える。 #buildersconC
2017-08-05 14:31:57Lamdba と連携する開発は確かにめんどいし、あと正直デバッグが辛すぎるのは同意。 #builderscon #buildersconc
2017-08-05 14:32:25まぁ確かにローカルでAPI gateway とかそこらへんはクソダルイけど、一応aws-serverless-express みたいなのがある。その場合ベンダーロックインの話は出てくるけど、vte.cxの独自仕様と、どう違いがあるかよね #buildersconC
2017-08-05 14:32:34「こだわった点。バックエンドの複雑さを隠蔽、API 設計に集中できる、ローカルの開発環境や CI/CD 環境を提供」個人的に三つ目は非常に重要なメリットだと思う。 #builderscon #buildersconc
2017-08-05 14:35:47どちらかというと個人的には、AzureとAWSとGoogleでそれぞれ対応し、完全に抽象化されたフレームワークを誰かが作ればそれでいいだけなのでは > ベンダロックイン #buildersconC
2017-08-05 14:36:42「REST API の定義は直感的でフォルダ構造と対応した規約になっている」さっきも書いたけど、Open API とかとの互換性はどうなる? #buildersconC
2017-08-05 14:38:46運用中のスキーマ定義変更した場合、マイグレーションはどうなるんだろ?自動で対応してくれるの? #buildersconC
2017-08-05 14:41:08まぁ、スキーマの自動マイグレーション、真面目にやるなら全部にuuidとかhashとか付けてそっちメインにしつつ、nameからIDをlookupする仕組みにしたりするかなー #buildersconC
2017-08-05 14:47:50qiita.com/stakezaki/item… vte.cxのトランザクションはこの記事に書いてるようだ #buildersconC
2017-08-05 14:49:42「かつてのアーキテクチャ。フロントの PHP がバグ多い、分割しすぎた Java のバックエンドの管理が大変、MySQL がスケールしない」 #builderscon #buildersconC
2017-08-05 14:50:07BaaSでマルチテナント云々はいいけど、それらの連携とか、それらの間にある独自処理とか、そういうてのヤツはどうするんだろ? #buildersconC
2017-08-05 14:52:52