# AIチャットbotのAPIの調査

https://docs.google.com/presentation/d/1eWbiOpvcH5LKMQ8wtiTOly4GRrA4tuWyVb8zhILbRA4/edit#slide=id.ge665714130_0_51

https://docs.google.com/presentation/d/1cwv6QNJhYAxunOhRnTD9Q5PVFlqxk3oc/edit#slide=id.p2

https://docs.google.com/spreadsheets/d/1NJXdWAPByXae2OFN-nFUzttOIsVRjk_4GeGGfh0PT8M/edit#gid=1192118438

## サーバの構築について
bapi_costomerの既存のアプリケーションにぶら下がる。

アプリケーションは開発できるが、その他重大な懸念点を見落としてないのか？
- 既存のコードへの影響をどのように切り分けるのか？
- エラーが起こり、他のコード部分でのエラーと競合する場合にめんどくさそう。
- コードの管理問題。
- 開発の問題。

- 一番の懸念点は今後の負荷分散をする時の移行のコストが高いこと。(インメモリのセッションをはることになる場合)ユーザは爆速に増えていかないということで大丈夫なのか？
- 今後の回収のツケがどっかで回るけどそこにコストを避けるのか？

## APIの不明点を明確にする。

### 確認したいこと
#### 認証部分(事前準備の部分)
- このお問い合わせチャットbotはログインしている人にしかできないことで合っているのか？(username, passwordはどこからとってくるのか？)バックエンドでのユーザの扱い方は？

- 1つのアクセスtokenのライフサイクルを知りたい。
アクセスtokenは1対話ごとに振られるという認識であっているのか？
同じユーザでも対話が変われば（次回問い合わせ）別のアクセスtokenで管理をするということであってるのか？

- アクセスtokenの管理の事例を教えて欲しい。
アクセスtokenはどこで管理する？変数（Redis）、DB、ElastiCache一般的な管理場所が分からないから事例とかを聞きたい。

- セッションが始まる場所がどこなのか？
最初の認証の部分から、セッションが始まるということなのか？

curl -L -X POST 'https://auth.wellvill.com/auth/realms/ROBOT/protocol/openid-connect/token' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Cookie: IDCF_ILB_SESSION=1f6162053d1644e289e13cce2f6a1b56' --data-urlencode 'client_id=ROBOT-client' --data-urlencode 'username=<USERID>' --data-urlencode 'password=<PASSWORD>' --data-urlencode 'grant_type=password'

#### セッション部分
- これも一般論が分からないから、事例を教えて欲しい。
変数(Redis)なのか、DBなのか、ElastiCacheなのかなど、セッションをどこで管理するのか？（今回の用件でボトルネックになる管理方法はあるのか？）
（インメモリに比べて1000倍ほど処理時間が掛かると言われている）
- 対話エンジンの空きを調べて、それを振り分ける。具体的な方法は？（事例はどのような感じ）
何度も空き状況を調べないといけないということだから、通信コストが発生すると思う。DB管理で大丈夫なのか？

- また、サーバが監視する。空き部屋と対話エンジンの実際の空き部屋の整合性はどのように取ればいいの？（共有メモリとかでできるのかなと思ったけど難しそう。）
- 実際に空き状況を取得するためのエンドポイントはどれになるのか？

#### 対話エンジンとフロントのメッセージ連携が開始するが、その橋渡しをベアーズがどこまでやり、対話開始してもらうかが謎

- 仕様書では全てサーバで管理しているが、それはどのような話になっているのか？


---
#### 対話結果のポスト部分
■やってほしいこと：
・①の調査、②の謎の点をクリアにする課題の明確化
・ドキュメント化して、いくつかの開発選択肢だし
・開発選択肢をよりクリアにするための、問の設定
■大きな設計上のポイント：
①認証：　tokenでAPIサーバと対話型エンジンが連携できる環境にしておく
②セッション管理：　フロントからチャット開始のリクエストもらう　＞　DBでセッションの使用状況を踏まえ、A.繋ぐセッションの指定　or　B.繋げないから有人よろしく、の結果をバックする　→　ただ、Aの場合、そこを元に、対話エンジンとフロントのメッセージ連携が開始するが、その橋渡しをベアーズがどこまでやり、対話開始してもらうかが謎　＆　「①」と「②」との連動が謎
③対話結果のポスト：　通常通り新しくAPI作って、パラメータおくってもらって処理するだけ。具体的にほしいパラメータの形や種類などは三田・長谷川で壁打ちしながら決める