2022技育祭_映写資料②

Transcript

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