サイト内検索
Translation here

2017/03/29(水)【前編】Microservices Meetup vol.5(API Gateway & BFF) #microserv

Finc.PNG

滑り込みセーフ!
今回は心臓に悪かったです……

WebAPI研究家の野村ごろう(@offficial_nomura)です
今日は勉強会3つ突っ込んでるので記事数がアレな事になってます。
なので「本日の議題」という言葉をアジェンダに差し替えてお届けしてます。

もちろん、無編集です。
素早い対応大事ですよね。

アジェンダ

思ったより話が早い(LTなので仕方ない)ので、ぽつぽつ飛んでます、申し訳ない。

Microservices Meetup vol.5(API Gateway & BFF)

Microservices Meetup vol.5(API Gateway & BFF)
当日絶対来る枠にねじ込んでやりました。大勝利!
……っていうワケでもないか。たぶんスタッフ枠じゃないかと思ってます。

APIのことはすべてシーマンが教えてくれた(@charlier_shoeさん)

すみません、遅れちゃったのでこの後で書いてます……

API運用の背景

API提供者とフロントエンド開発者とのコミュニケーション

APIに求められること

  • 扱いやすさ
    • 正常系・異常系
    • ライフサイクル
    • ドキュメント
    • すぐに試せる
  • 疎結合
  • 利用量監視
  • 流動制御
  • セキュリティ
注)APItoneとかなんだっけアレ?使えると思う。

マイクロサービスで活用するAPI

API Gatewayを使って細かい問題を解消してしまおう!

不要なデータが多い

面倒くささを解消してあげる
Backend for Frontend
ざっくり言うと、
  • API仲介レイヤー
  • 最適化した形式に変換する

OracleクラウドでAPI Platform Cloud Service(以下PCS)を出すよ!という話

これ書いていいのかな……?
Enterprise Cloud Computing SaaS, PaaS, IaaS | Oracle Cloud

Oracle APIPCSのドキュメントの話

もちろん英語です。技術者なら英語読んでください。
たぶん、見た目にマークダウンっぽく書けるな、というところさえ気づけばそんなに難しくはないというか、参加障壁は低そうです。

Oracleのデベロッパ―イベントが実施されます!

これはすごくアツい!参加条件とか気になりますね~。

step by step BFF(@yosuke_fukukawaさん)

登壇者紹介

[(filter unkown) ]
Node.jsでガリガリ
レガシーソフトウェア改善ガイド(Amazon)
似たような本でレガシーコード改善ガイド(Amazon)がありますが、今回はこちらではないらしく。

BFF is なに?

Backends For Frontendsを略してます。
オライリー本出てきたぞ……

色々使える子。
APIまとめるくん
登壇者がそう言ってたのでそう書きます。
各種APIをBFFで持っちゃうおぢさん。細かい話を全部まとめていい感じにやってくれるのもここ。
実は似たような事をやってるものは色々あって、とはいえトークンとかセッションとかその辺をいい感じにやろうとするとそれはそれでアレな管理になるので結構面倒くさかったりする。
ファイルアップロード
ファイルアップロードのゴニョゴニョをいい感じに出来る。
チャンク化の話。この辺は後で調べた方がいいかも。明らかに私のスキルが足りてない。
WebSocket/Longolling/SSE
接続関連の話。

BFFの歴史的な話

  • 初期(90年代)
    クライアント側では表示のみ、細かいのは全部サーバーでやる
  • 成長期(00年代)
    フロント側に描画関連ロジックを寄せる(フロントエンド)
  • 現行
    サーバー負荷を減らしてマイクロサービス化していく
    サーバー側はBFFを一つ置いている(MVCでいうところのコントローラみたいな)

BFFをNode.jsにするメリット

クライアント側のロジックを共通化出来る。Reactっぽい話。
キャッシュ関連も扱えるとGood
バリデーションとかも持ちたい。

事例

デバイス事に対応する必要がある
  • APIを最適化するよりは呼び出し側で最適化してあげる
  • 通信方式などをBFFで抱き込んでしまう

BFFを導入する時、しない時

フロント・バックの分業を促進させる。
フルスタックエンジニアが多い場合

step by step

  • 既存システムがあるならProxyにする
  • レンダリングするレイヤのみ担当させる
  • リアーキテクチャの必要があればちょいちょいと
徐々に入れていくのが理想的

Webサービスの初期開発とマイクロサービスBFF(@shimpeiwsさん)

登壇者紹介

Ruby on RailsとJavaScriptを書いてる方

要件・アーキテクチャ

Webからスタートするが、ネイティブアプリが出る可能性が高い
toCはスマートフォン。UIとか細かい話をちょいちょい言われる
  • フロントエンド
  • サーバサイド
  • インフラ

開発の歴史

  • 立ち上げ
    • 基本機能をゴリゴリ
    • アーキテクチャ設計十四
  • 初期
    • バグや負債を返済していく
    • スクラム開発運用
  • 中期
    • グロースハック施策
    • チーム分割とマイクロサービス化

大事なこと

立ち上げ期ー開発初期にアーキテクチャ・設計上考えたい事
  • Single Page Aplication + SSR構成にしたい
  • React + Redis導入
  • API設計の単純化
    • 1モデル1APIになることが多い→初期レビューでチーム内の意識統一
  • 後から考えられる余地のあるアーキテクチャ設計は大事

デモ

BFFを入れる前と後の話。
この辺は説明されないと見た感じの話しか分からなかったので書けない……
言ってることは分かる。

サンプルコードがgithubにあるので、後で見ておこう!

ウェルネスタイム

今回はなし。
→ありました。
この辺りから前倒してるすげぇ!

~後半へ

Apitore WebAPIハンズオン Vol.1 @大手町 #apitore
OK キャンセル 確認 その他