Slide 1
Slide 1 text
No content
Slide 2
Slide 2 text
経験言語：Python、PHP、React、Vue（どれも少しずつ）
趣味：ゲーム（鉄拳、Apex）、アニメ、音楽（BUMP、椎
名林檎、ボカロ…etc）
好きな食べ物：ラーメン二郎、麺類、ハンバーガー
Name :
佐藤ゆ(エンジニア)
Slide 3
Slide 3 text
技術調査（Poc）
Slide 4
Slide 4 text
？
PoC（Proof of Concept：概念実証）とは
Slide 5
Slide 5 text
PoCとは？
● 新たなアイデアやコンセプトの実現可能性やそれによって
得られる効果などについて検証すること
● これによって事前に検討したアイデア／コンセプトの実現
可能性を見極め、期待した効果が得られると判断できれば
実プロジェクトを進めていくという形が一般的です。
Slide 6
Slide 6 text
BFFとは？
Slide 7
Slide 7 text
？
フロントエンドのための
バックエンドサーバー
Slide 8
Slide 8 text
BFFとは？
● 従来のモノリシックなサービスからマイクロサービス化
○ 複数のAPIを叩く必要が出てくる
Slide 9
Slide 9 text
BFFとは？
● 取得したデータの加工をフロントエンドで行う必要有り
○ フロントエンドで表示する内容は往々にして変わるた
め、加工処理はフロントエンドがいいかも・・・
○ APIで取得してきたデータの一部は不要なため削ぎ落
としたり・・・（インピーダンスミスマッチ）
● フロントエンドの肥大化
● そもそもフロントエンドはUI/UXに専念するべき
Slide 10
Slide 10 text
BFFとは？
BFFを用意することでAPI集約、インピーダンスミス
マッチの解消、責務・関心の分離、パフォーマンス
の向上が見込めるってコト！？
Slide 11
Slide 11 text
BFFとは？
デメリット
● 開発・保守の工数増
● 通信量増
● マイクロサービスのどれかがダウンした際の運用などを考
える必要やBFFが停止した場合など、様々な観点から検
証・対策が必要
（通信量の対策としてはキャッシュ化などが挙げられる）
Slide 12
Slide 12 text
ユースケース
Slide 13
Slide 13 text
2. SSR（Server Side Rendering）
4. File Upload
5. Web Socket
3. Session Management
1. API Gateway
Slide 14
Slide 14 text
● APIの結果を一つに集約する（API Aggregation）
● APIで取得したデータをフロントエンドに適したデータに加
工する（API Translate）
● 余計なリクエストが増大しないようAPIのレスポンスをキャ
ッシュ化（API Cache）
○ Chache-aside pattern
○ Broker pattern
● GraphQLとの相性が良い
API Gateway
Slide 15
Slide 15 text
● GraphQLとの相性が良い
API Gateway
Slide 16
Slide 16 text
Server Side Rendering
● CSR（Client Server Rendering）と違い、サーバーでレンダ
リングを行う
○ CSRと比較するとSEO観点で有利だったり、ローディング時間が短いと
いったメリットがある
● みなさんお馴染みのNext.js、Nuxt.jsで簡単に実装可
○ Next.jsはデフォルトでSSRの設定になっています
○ たまにhydration周りでエラーになったり・・・
● SSG（Static Site Generation）もあるが、こちらは静的サイ
トに向いている
SSR
Slide 17
Slide 17 text
● 主にユーザーの情報など、頻繁にアクセスされるであろうデ
ータを保存する
○ Redisやmemcachedなどが多く使われるらしい
● 仮にBFFで管理をしない場合
○ クライアント側でLocal StorageやCookieなどで管理する必要がある
■ セキュリティ的によくないよね
○ バックエンド側で処理を重複して実装する必要がある
■ なんか面倒くさそう
Session Management
Slide 18
Slide 18 text
● 多くの場合はファイルアップロード機能を実装するとチャンク
化してファイルを少しずつ送信することが多い
○ Pythonのrequestsとか、PHP(Laravel)のlaravel-chunk-uploadとか
○ チャンク化したデータを順番通りにバックエンドに送信するのは大変そう
File Upload
ファイル格納の処理を
BFFが担うことで
シンプルに実装可能！
Slide 19
Slide 19 text
● クライアントとサーバー間で即時に通信を行うHTTPの拡張
機能
● チャットや同時編集機能(googleスプレッドシートとか)や
SNSで使用される
● BFFがリアルタイムにデータ交換をする処理を受け持つこと
で、バックエンドはデータをDBに保存することだけに集中
できる。
Web Socket
Slide 20
Slide 20 text
Web Socket
①
② ③
③’
Slide 21
Slide 21 text
● クライアントとサーバー間で即時に通信を行うHTTPの拡張
機能
● チャットや同時編集機能(googleスプレッドシートとか)や
SNSで使用される
● BFFがリアルタイムにデータ交換をする処理を受け持つこと
で、バックエンドはデータをDBに保存することだけに集中
できる。
Web Socket（改めて）
Slide 22
Slide 22 text
BFFまとめ
Slide 23
Slide 23 text
まとめ
● BFFには5つのユースケースがある
● BFFにメリットがたくさんあるが、デメリットも勿論あるため、
要件によって採用するしないを決める必要がある
● （個人的には）責務の分散、API集約によるメリットが大きいの
で、新規プロジェクトでは検討して良さそう
Slide 24
Slide 24 text
？
GraphQLとは
Slide 25
Slide 25 text
GraphQLとは？
※https://graphql.org/
Slide 26
Slide 26 text
GraphQLとは？
※https://graphql.org/
Slide 27
Slide 27 text
GraphQLとは？
● Facebookが開発したよ
○ REST APIを使用していたらクラッシュが頻発したため、
より効率的にデータを取得するためGraphQLが開発された
○ Facebook、Netflix、GitHub、Twitterも使用してるみたい
● query言語で柔軟なデータ取得が可能
○ 複雑な関係のデータでも取得しやすい（自分比）
● エンドポイントが単一
○ ユーザー情報は/users/ 、商品情報は/products/
○ GraphQLだと /graphql/でユーザーも商品も取れちゃう
● スキーマの構造がグラフモデル
○ 詳しくはデータモデルに関して調べてみてください
Slide 28
Slide 28 text
GraphQLとは？
● RESTとGraphQLを比較してみる
REST API
https://docs.github.com/ja/rest/guides/getting-started-with-the-rest-api
GraphQL API
https://docs.github.com/ja/graphql/overview/explorer
尚、ユーザーID・ユーザー名・アバターURLのみがほしいとする
Slide 29
Slide 29 text
GraphQLとは？
REST API
● これって・・・
過剰にデータ取得しすぎってコト！？
探せば他に良いエンドポイントありそう。
って思ったけど探すのめんどい
Slide 30
Slide 30 text
GraphQLとは？
GraphQL API
● 取得したいデータのみ抽出できた
Slide 31
Slide 31 text
SQL GraphQL
SELECT query
INSERT/UPDATE/
DELETE
mutation
- subscription
GraphQLとは？
Pub Subのような仕組みのリアルタイム通信
特定の情報を監視するようなイメージです
Slide 32
Slide 32 text
GraphQLとは？
GraphQL API
デモ
Slide 33
Slide 33 text
REST API
● 複数のエンドポイント
● 取得するデータが決まっている
○ 過剰な取得
○ 過少な取得
● 欲しいデータによっては複数回リ
クエストを投げ、取得したデータ
を加工して・・・といった手間が
かかる
GraphQL
● 単一のエンドポイント
● 取得したいデータをピンポ
イントで抽出できる
○ スキーマで定義したデータだけ
だからなんでも取得できるとは
思わないこと
● BFFとの親和性高そう
GraphQLとは？
Slide 34
Slide 34 text
GraphQLまとめ
Slide 35
Slide 35 text
GraphQLまとめ
● GraphQL良さそうだけどN+1問題とか性能が少し気になる
● BFFにするならGraphQLあり
● 今後はGraphQLが採用されることも増えていくのではないか
Slide 36
Slide 36 text
技術調査まとめ
Slide 37
Slide 37 text
技術調査まとめ
● 技術を導入した際のメリデメを考える
● 導入障壁はないか
● 導入コストや開発後の運用保守（メンテナンス）まで検討する
といったことを調査を行った上で検討する
Slide 38
Slide 38 text
おわり