はじめに
今年度こそAPIを開発したいと思います。
そこで、APIを開発するにあたり、しっかりとした知識を持って設計をしたいと思います。
振り返りにも活用するために、本メモに参考とした情報を残します。
サービスの粒度
まずは、マイクロサービスについて、そもそもサービス分割の考え方を学びたいと思います。
参考にしたのは、クックパッドさんのクックパッドにおける最近のMicroservices事例です。
クックパッドさんによると、以下の3つのタイプに分類しているとのこと。
- ユーザーサービス
- 大原則は、事業ドメイン（プロダクト）で分割すること
- プロダクトが異なれば対象ユーザーも異なるので、柔軟な技術選定ができるはず
- ビューサービス
- BFFに近い
- 同じドメインモデルを別バージョンで提供する場合に使う
- 共通基盤サービス
- サービス間で共通的使われるサービス。
BFFとは
Backends for Frontendsの略。SoundCloud開発中のPhil Calçado氏による造語。
マイクロサービスアーキテクチャ著者のSam Newman氏によれば、
ユーザエクスペリエンスごとにひとつのAPIバックエンドを用意する方法だ。概念としては，ユーザ向けアプリケーションが２つのコンポーネントで構成されることになる。ひとつがクライアント側で，もうひとつがサーバ側という
マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング によると、ECサイトを表示する際、4つに分割されたサービスからデータを取得するためには、単純に考えると4回のAPIコールをしなければならなくなり、モバイルの通信料や画面描画の遅延にも繋がってしまう問題が発生する。
この問題を解消するために、API ゲートウェイの採用を紹介されており、加えてBFFの考え方についても触れられている。
APIゲートウェイを、呼び出しデバイスおよびアプリケーションごとに分離し、その管理責任を呼び出し側アプリケーションのチームに渡すのが、Backends for Frontends (BFF)です。
参考サイト
- フロントエンドに対するAPIバックエンドの提供パターン
- マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング
- 綺麗なAPI速習会
- マイクロサービスのための綺麗なAPI設計
- Webサービスの初期開発とマイクロサービス・BFF
- APIのことはすべてシーマンが教えてくれた
- step-by-step BFF
- Microservices Meetup vol.5 (API Gateway & BFF)に参加しました！
- RESTfulなWeb APIを設計するときに考えること
- Web API: The Good Partsを読んだので「設計変更しやすいWeb API」についてまとめた
- Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love"
- OAuth2.0をかみくだく