Enterpriseapi20160210

Copyright © Virtual Technology, Inc
APIだけで
フロントエンド開発を可能にした話
2016/2/10 有限会社バーチャルテクノロジー
1

•  ⽵嵜伸⼀郎（たけざきしんいちろう）
twitter id:stakezaki
元⽇本IBM（ソフトウェア事業部）
元株式会社暮らしのデザインCTO
•  Virtual Technologyにて
企業向けKVS・BaaS等を開発
ReﬂexWorks
vte.cx
2

Copyright © Virtual Technology, Inc3
⼤規模 Web帳票システム by ReﬂexWorks
　APIのスループット
７万ユーザ/日 40万伝票/日　
　６００tps !
　　※ DBはその１０倍以上

vte.cx (ブイテックス) engine
• http://admin.1.vte.cx
4
2015/12 βリリース

vte.cx engine の概要
KVS
Web
スマホ

•  Web(スマホ)システム向けBaaS(Backend as a Service)
–  CMS(Content Management System)機能
–  トランザクションサポート
–  ユーザ・グループ管理
–  サーバサイドJavaScript
–  EXCEL⼊出⼒機能
–  PDF帳票出⼒機能
オンライントランザクション処理データ分析
※ 2016年春リリース予定

サーバレスアーキテクチャーの課題
6

今注⽬のサーバレスアーキテクチャー
7
API Gateway
Lambda
Cognito SNS DynamoDB
Cloud Front
S3
client
mobile client

サーバレスアーキテクチャーは
Webアプリに使えるか？
8

設定地獄の懸念
• 静的コンテンツとAPIが異なるドメイン
–  CORSの設定、あと、セッションどうすんの？
• 各サービス利⽤には認証が必要
–  CognitoのSecurity Token Serviceで設定
• そもそも考慮の必要がなかったことでは？
• サーバレスのはずなのにサーバの設定が必
要ってどういうこと？
9

API以外の余計なことは考えたくない
10
サーバの中で複数のサービスに分かれようが
クライアントにとってはどうでもいい
適当に分散して勝⼿にスケール
これが真のサーバレス

vte.cxのアプローチ
11

サーバレスWeb開発の⽬標
• vte.cxはフロントエンドエンジニアだけで
Webアプリを開発することを⽬標にした
サーバサイドのことは本当に何も考えない
• SPA(SinglePageApplication)の採⽤と⾃由なAPI設計
–  HTMLやJavaScriptのコーディングのみ
–  ACIDトランザクションに対応
• ローカル開発環境の提供と簡単なデプロイ
12

- ポイント１ -
サーバサイドレンダリングをやめSPAを採⽤
•  SPAは優れたUXを提供することを⽬的とする
１つのWebページで提供されるアプリケーション
–  クライアントはXHR等でサーバにリクエストし、結果
をJSONなどのデータで受取る
–  ページの再読込せずにJavaScriptで動的に更新する
13

増えたフロントの責務と残る課題
h:p://www.slideshare.net/fullscreen/sagawafumio/ss-38480894/6
ここをどうするか？

- ポイント2 –
直感的なREST APIを作る
•  フロントエンジニアが⾃由に設計できるようにする
–  URIの設計
–  スキーマの設計
重要：データだけでなく
HTMLなどの静的
コンテンツも同じ扱い

スキーマ
•  シンプルなシンタックス
– 「項⽬名（型）＝正規表現」の形式で記述
•  バリデーション
– 正規表現で値をチェック
•  ソフトスキーマ
– 項⽬の追加が可能
•  Index
– Index指定が可能
20
booking
registration_no=d{0,7}-d{0,2}$
date(datestring)!=^d{0,2}/d{0,2}/d{0,2}$
type[]!=^Foo$|^Bar$|^Buzz$
payment_method_name!=^[0-9a-zA-Z]{0,15}$
shipper
customer_no=^d{0,6}$
company_name!=^[a-zA-Z0-9- .,/:@`~()'%]{0,50}$
zipcode!=^d{3}-d{4}$

vte.cxのトランザクション管理
•  Feed(Collection)単位のAtomicトランザクション
–  分離レベル：REPEATABLE READ
•  かつ、Entry単位のバージョン⽐較
–  分離レベル：SNAPSHOT ISOLATION
–  全てのEntryはURLとリビジョンで管理される
–  リビジョン＝更新されると＋１される
21
https://www.facebook.com/notes/virtual-technology/
bdbトランザクションとreﬂexworksの処理について/486790368009209
データの⼀貫性を確保しつつ⾼いスループットを実現
詳細：

- ポイント3 -
ローカル開発環境
• リバースプロキシでクロスドメインを回避
• サービスのURLだけをサーバに向ける
22
/d/master
ローカル環境で
開発しているイメージ

CircleCI
23
GitHubにPushすることで⾃動的にサーバにデプロイ
※ 設定方法はAdvent Calendar の13日目に記載

vte.cx開発⼿順
• 管理画⾯でサービスを新規作成
• Githubのvtecxblankをclone
• コンテンツを作成、APIを作成
• コンテンツをGitHubにpushすることで
サーバにデプロイ
–  もしくは、gulpコマンド⼀発
• データをREST APIで操作
たった、これだけ。
これですべてのWebシステムを開発できる
24

本当は複雑なサーバサイド
•  マルチテナントアーキテクチャー
•  KVSであることを意識させない（ドキュメント型）
•  並列分散したノードがMicroservices的に連携
複雑さを一切
表に出さない

まとめ
•  サーバの複雑さは隠蔽すべき
–  現状のサーバレスアーキテクチャーは構成の都合を
クライアントに押し付けているように思える
–  Microservicesも同様。モノリシックを分解してThin
にするのはいいが、認証などの考慮をクライアント
にさせるのは不味い
•  Webアプリのことだけに集中すべき
–  重要なのはAPIとスキーマ設計(+ACL)
–  静的コンテンツを含めSame Originで管理する
•  ローカル開発環境・デプロイ環境は重要
–  ⼤規模なWeb開発ではローカル開発環境は必須
–  コマンド⼀発かGithubにpushで⾃動デプロイ
26

余談：MicroServices
隠蔽されるサーバ技術に標準化は必要か？
•  JSON Schema、Swagger(Open API)
•  AccessToken関連
–  JWT(JSON Web Token)
–  OAuth 2.0 Token Introspection (RFC7662)
などを駆使してMicroServicesを使いこなそうとしている正
直者が多い。⼀体誰得なの？
標準に準拠しているのとインターオペラビリティは別の問題
私たちは開発⽣産性の⽅が重要だと考えて、結局、(独⾃)ス
キーマとワンタイムトークン(RXID) を採⽤した
詳しくは「WebAPI認証」で検索
27

私たちのビジネスの話
• Webアプリの受託開発でvte.cxを活⽤
• オンプレミスvte.cx(ReflexWorks)の販売
• 将来的にBaaS vte.cxの有償版
–  全然流⾏る気配なし。
–  たぶん、BaaSはビジネスにならないだろう
28

Qiita Advent Calendar 2015
h:p://qiita.com/advent-calendar/2015/vtecx?share=true

ご清聴ありがとう
ございました
Blogも書いています
ぶいてく

Enterpriseapi20160210

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Enterpriseapi20160210

Similaire à Enterpriseapi20160210 (20)

Plus de Shinichiro Takezaki

Plus de Shinichiro Takezaki (6)

Enterpriseapi20160210