API Gateway パターンに関する図(PlantUML)

API Gateway パターンに関する図を PlantUML で作成しました。
この図を含んだブログ記事も記載しているので、興味あるかたは以下からどうぞ。

[すごいよ、API Gateway パターン！ 〜 マイクロサービスアーキテクチャの設計パターン 〜 - ふじやまエッグの日々](https://fujiyamaegg.hatenablog.com/entry/2020/07/03/002744)

# API Gateway パターン
クライアントとバックエンドのサービスの間に玄関口となるAPIゲートウェイを置くのが、API Gateway パターンです。

## APIゲートウェイがある場合
APIゲートウェイが外部からのリクエストを一手に引き受けます。

![apigateway.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73241/b85e7715-39c8-cbc0-c1cb-18ec86257bc1.png)

<details>
<summary>コード</summary>
<pre>
@startuml
title APIゲートウェイがある場合
skinparam agent {
  roundCorner 20
}
skinparam rectangle {
  roundCorner 20
}
agent クライアントアプリ as client
rectangle バックエンド as backend {
  agent APIゲートウェイ as gateway
  agent サービスA as serviceA
  agent サービスB as serviceB
  agent サービスC as serviceC
}
client -right-> gateway
gateway-down-> serviceA
gateway-down-> serviceB
gateway-down-> serviceC
@enduml
</pre>
</details>

## APIゲートウェイがない場合
APIゲートウェイがない場合は、以下のように外部からのエントリポイントが複数に分散します。これは、外部からの攻撃ポイントも複数に分散することにもつながり、セキュリティリスクを高めることになります。

![noapigateway.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73241/0108cf40-6a48-6659-7f40-3101b8ee3546.png)


<details>
<summary>コード</summary>
<pre>
@startuml
title APIゲートウェイがない場合
skinparam agent {
  roundCorner 20
}
skinparam rectangle {
  roundCorner 20
}
agent クライアントアプリ as client
rectangle バックエンド as backend {
  agent サービスA as serviceA
  agent サービスB as serviceB
  agent サービスC as serviceC
}
client -down-> serviceA
client -down-> serviceB
client -down-> serviceC
@enduml
</pre>
</details>


# API Gateway シーケンス図

## APIゲートウェイを経由しない場合
APIゲートウェイを経由しない場合は、クライアントから複数のサービスから必要な情報を取得するようになります。シーケンス図は、以下のようになります。

![seq_noapigate.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73241/d5ef5ba8-9e98-3f24-3293-ca67e83d4cc7.png)

<details>
<summary>コード</summary>
<pre>
@startuml
title APIゲートウェイを経由しない場合
participant “ECサイト注文画面” as ecsite
participant “商品カタログサービス” as catalog
participant “レビューサービス” as review
participant “レコメンデーションサービス” as recomendation
ecsite -> catalog: 商品情報取得()
activate catalog
catalog-> ecsite : 商品情報
deactivate catalog
ecsite -> review: レビューリスト取得()
activate review
review -> ecsite : レビューリスト
deactivate review
ecsite -> recomendation: レコメンデーションリスト取得()
activate recomendation
recomendation -> ecsite : レコメンデーションリスト
deactivate recomendation
@enduml
</pre>
</details>



## APIゲートウェイを経由する場合
APIゲートウェイを経由する場合は、クライアントとのやりとりを最小限におさえることができます。


![seq_apigate.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73241/eca7c17e-3ac0-6ed8-af1e-b23d57da1c01.png)


<details>
<summary>コード</summary>
<pre>
@startuml
title APIゲートウェイを経由する場合
participant “ECサイト注文画面” as ecsite
participant “APIゲートウェイ” as apigateway
participant “商品カタログサービス” as catalog
participant “レビューサービス” as review
participant “レコメンデーションサービス” as recomendation
ecsite -> apigateway: 注文画面用情報取得()
activate apigateway
apigateway-> catalog: 商品情報取得()
activate catalog
catalog-> apigateway: 商品情報
deactivate catalog
apigateway-> review: レビューリスト取得()
activate review
review -> apigateway: レビューリスト
deactivate review
apigateway-> recomendation: レコメンデーションリスト取得()
activate recomendation
recomendation -> apigateway: レコメンデーションリスト
deactivate recomendation
apigateway -> ecsite : 注文画面用情報
deactivate apigateway
@enduml
</pre>
</details>



# 最後に
APIゲートウェイは、マイクロサービスアーキテクチャにおける玄関口の役割を担います。そんなAPIゲートウェイに関して以下の記事にまとめているので、興味あるかたはぜひどうぞ。

[すごいよ、API Gateway パターン！ 〜 マイクロサービスアーキテクチャの設計パターン 〜 - ふじやまエッグの日々](https://fujiyamaegg.hatenablog.com/entry/2020/07/03/002744)