Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cookpad summer internship 2019 - API

Cookpad summer internship 2019 - API

A lecture slide for https://internship.cookpad.com/2019/summer/ (Day 3 ).

Ken Wagatsuma

August 21, 2019
Tweet

More Decks by Ken Wagatsuma

Other Decks in Programming

Transcript

  1. 講師: @kenju_wagatsuma • 我妻 謙樹(Kenju Wagatsuma)
 • メディアプロダクト開発部マーケティングサービス開発グ ループ
 •

    広告配信サーバー・入稿システム・リアルタイムログ基盤等 広告にまつわるシステムの保守運用

  2. 広告関連システム概要 Operation Team Data Warehouse Ad Creative Optimization Ad Campaign

    Ordering Service Ad Delivery Service Targeting Service Delivery Metadata Mobile Client Ad Creatives log
  3. Linux OS Docker, Terraform, Jenkins DevOps Nginx, Fluentd, ELB Infra

    Ruby Rails TypeScript React.js GraphQL Apollo Ruby Rails Go AWS ElastiCache AWS DynamoDB Service Mesh Envoy Python AWS APIGateway AWS Lambda Tableau Application SQL AWS Redshift AWS Athena Ruby Python AWS Kinesis AWS DynamoDB AWS Lambda Batch Layer Streaming Layer Ad creative admin service Ad delivery service Logging Machine Learning 広告関連システム選定技術一覧
  4. Timeline • 1000-1130 講義パート A(基礎編)
 • 1130-1300 Handson
 • 1300-1400

    ランチ
 • 1300-1400 講義パート B(応用編)
 • 1400-1830 Exercise
 ※ 休憩は各位適宜取得してください

  5. tl;dr • Backend-For Frontend(以下:BFF) を Node.js / GraphQL / TypeScript

    を使って開発します
 • 現場の実際の開発にかなり近い開発体験を経験することが できます

  6. NOTE • ハンズオン編は zoom で画面共有します
 ◦ WiFi 接続速度によって柔軟に対応しましょう
 • 後日インフラの日に触れる技術要素は

    Blackbox で行きま すので心配しないでください
 ◦ e.x. hako, SAM, DynamoDB, facebook/dataloader, etc.

  7. BFF

  8. What’s BFF? • Pattern: Backends For Frontends by Sam Newman,

    the author of “Building Microservices” • Definition: “Single-purpose Edge Services for UIs and external parties” https://samnewman.io/patterns/architectural/bff/
  9. One of “API-Gateway” Patterns https://microservices.io/patterns/apigateway.html BFF は API-Gateway Patterns と呼ばれる設計パ

    ターンの一種。 ※ RESTful API / GraphQL は実装の詳細である。 GraphQL だけが BFF では ない点に注意。
  10. Legacy New RESTful API, GraphQL Schema BFR Backend for Resource

    BFF Backend for Frontend Frontend Resource Resource Legacy Usecase New Usecase
  11. About GraphQL • API のためのクエリ言語の仕様
 • Facebook で 2012 年から開発され、2015

    年に OSS 化、そ の後 GraphQL Foundation が設立されるなどコミュニティも 拡大
 • JavaScript や Ruby を始めとした実装多数

  12. BFF x GraphQL 以下の Backend Resources を Client に対 して隠蔽する設計パターン

    • RDBMS/NoSQL などの Datasource • 新規システム • 既存システム • 3rd-Party API https://www.howtographql.com/basics/3-big-picture/
  13. Query • データを取得するための操作を定義
 • 欲しいデータの、欲しいフィールドを宣言的に書く
 ▪ 利点
 • Over-fetching /

    Under-fetching を防ぐ
 • クライアント開発において欲しいデータを宣言的 に書けることで保守性が向上

  14. pantry Koresuki (Likes) BFF (GraphQL) Schema pantry AWS API Gateway

    Mobile Client AuthoCenter AWS Lambda AWS DynamoDB voyager user backend
  15. クライアント側仕様 • Cookpad 本体アプリも利用している同等の Backend Service を利用します
 ◦ “pantry” と呼ばれる


    • 「いいね」機能はフルスクラッチで実装します
 ◦ AWS サービス群を利用した Serverless 構成

  16. pantry Koresuki (Likes) BFF (GraphQL) Schema pantry AWS API Gateway

    Mobile Client AuthoCenter AWS Lambda AWS DynamoDB voyager user backend BFF & Koresuki を
 実装します

  17. “Simple” !== “Easy” • Likes の状態はどうやって保存する?
 • pantry と Koresuki

    の結果をどう JOIN する?
 • GraphQL のキャッシュが必要になったらどうしたらよい?
 • 認証 (Authorization) に失敗したときは何を表示する?
 • pantry が死んだ時の retry 戦略はどうする?
 • Koresuki はどうスケールさせる?
 • NoSQL におけるインデックスはどう貼る?
 • 非機能要件をどこまで実装できる?
 • ID Token の検証が Bottleneck になった時、どこを改善する?
 • etc.

  18. Pantry • Cookpad レシピサービスのリソースを HTTP で操作するた めの API Server
 •

    May 2013~ から開発スタートされた Rails app
 • レシピ一覧、レシピ詳細、カテゴリ一覧、殿堂入りレシピ、検 索、人気順、... etc.

  19. AuthCenter • OAuth2 認可を行うための Web application
 • RFC 6749 (The

    OAuth 2.0 Authorization Framework) に 則った基本に加え、固有の拡張がいくつか存在する
 • アクセストークンの発行, アクセストークンの検証

  20. AuthoCenter(通称:大嘘センター) • @KOBA789 謹製, Rust 製
 • Summer Internship 用に作られた

    AuthCenter を模した Web application
 • 任意の user_id を渡すと ID Token が発行される

  21. ID Token • JSON Web Token (JWT) を署名したもの
 ◦ RFC7519


    • 署名方法
 ◦ JSON Web Signature (JWS) RFC7515
 ◦ JSON Web Key (JWK) RFC7517

  22. ID Token header
 body
 signature
 .
 .
 Base64 Encode された

    JSON Web Token (JWT) 
 
 { “iss”: “https://….”, “sub”: “16672509”, .... } ※ JWS で JWT を署名した形式 

  23. AWS API Gateway • HTTP な RESTful API のためのマネージドサービス
 •

    Canary Release や認証機能等 API 開発には欠かせない機 能提供の他、CloudWatch と連携した Logging/Monitoring/Alerting などが有用

  24. Error Handling w/ GraphQL • HTTP Status = 200 OK

    のまま、“errors” にエラーの Stack traces を含める
 ◦ https://graphql.github.io/graphql-spec/June2018/#sec-Errors
 • あくまで Best Practices(apollo-server や graphql-ruby など 多くのツールが従っている)

  25. Error Handling w/ GraphQL • 理由
 ◦ 例)pantry へのリクエストがエラーになったからって、他 の

    Backend Resources からのレスポンスなど全ての フィールドが エラーになると、GraphQL を BFF としてら 使う旨味が半減
 ◦ 返せるものは返す

  26. 例)
 前提条件
 • “name” field が Non-Null
 • id=1002 のデータは、”name”

    field が Null
 結果
 • id=1001, 1003 の結果は返却され る
 • “errors” field に id=1002 のデー タが取得できない理由を格納。ど う処理するかはクライアント次第

  27. Relay Cursor Connection • https://facebook.github.io/relay/graphql/connections.htm
 • Pagination に関する Practice の一つ


    • GraphQL Framework の一つであり、Facebook が主だって 開発している Relay で実装されている
 • Connection/Edge/Node/PageInfo

  28. Example)
 • edges
 ◦ edge (node + cursor) の配列 


    • cursor
 ◦ カーソル。一連の Edges にアクセス する際の現在位置を表現 
 ◦ String に serialize 可能な型 
 • node
 ◦ Pagination で返却したいデータ 
 • pageInfo
 ◦ hasNextPage & endCursor 
 ◦ hasPreviousPage & startCursor 

  29. graphql/dataloader • Caching
 ◦ 同じ Request Parameters のレスポンス結果は、リクエス トごとにキャッシュして再利用
 •

    Batching
 ◦ Promise (JavaScript の標準 API)を利用して resolver を遅延評価、同じリクエストは一括処理(batch)する