🤔 이슈
지난번의 회의끝에, 쿼리스트링 방식보다는, body에 담아서 JSON형태로 fastAPI서버에 사용자의 선택 정보를 전달하는게 더 나은 선택인 것 같다는 생각을 했다. 왜냐하면 기존에 보영이가 설계한 DB방식이 JSON형태이기도 하고, 정보 전달할것이 많아지면 텍스트 길이가 끝도 없어지기도 하기 때문에, body에 담아서 넘겨주는게 가장 좋은 방법이라고 생각했다.
=> 그래서, 이전 이슈에서 작성했던 쿼리스트링 방식을 BODY에 담아서 서버에게 정보를 보내는 방식으로 변경하려고 한다.
💫 통신 시나리오 이해하고 시작하기
보영이의 DB설계에 의하면, 사용자의 선택에 대해서 다음과 같은 요청을 넘겨줘야한다.
(1) 사용자 설정 완료 후, 다음으로 넘어가는 순간

[ React 서버 측 --> fastAPI 서버 ]
{
"voice_id": 1,
"situation": "school",
"start_time": "2024-07-27T16:13:00.353Z",
"my_role": "학생",
"ai_role": "선생님"
}
[ fastAPI 서버 측 --> React 서버 ]
그러면, fastAPI 서버측에서는 history값을 프론트에게 다음과 같이 넘겨줄거다.
이게 무슨 의미이냐면, 지금부터 채팅을 하면서 진행되는 채팅은 history_id 1번으로 전달해줘라~라는 의미이다.
이제 채팅페이지로 넘어가서 채팅을 진행하게 될텐데, 프론트측은, 채팅이 진행될때마다, 서버에게 history_id 1번에 해당하는 채팅임을 알려줘야한다. 그러면 이후에 진행될 채팅에서 프론트는 채팅 정보를 fastAPI 서버가 전달해준 history번호로 전달하면 된다.
(2) 채팅을 진행하면서

[ React 서버 측 --> fastAPI 서버 ]
{
"message": {
"question": "어디가 아파서 왔나요?"
},
"chat_history_id": {
"history_id": 15
}
}
[ fastAPI 서버 측 --> React 서버 ]
그러면 서버측에서는 LM Studio의 응답을 받아서 프론트에게 이렇게 응답할 것이다.
{
"message": "머리가 아파서 왔어요"
}
🤔 이슈
지난번의 회의끝에, 쿼리스트링 방식보다는, body에 담아서 JSON형태로 fastAPI서버에 사용자의 선택 정보를 전달하는게 더 나은 선택인 것 같다는 생각을 했다. 왜냐하면 기존에 보영이가 설계한 DB방식이 JSON형태이기도 하고, 정보 전달할것이 많아지면 텍스트 길이가 끝도 없어지기도 하기 때문에, body에 담아서 넘겨주는게 가장 좋은 방법이라고 생각했다.
=> 그래서, 이전 이슈에서 작성했던 쿼리스트링 방식을 BODY에 담아서 서버에게 정보를 보내는 방식으로 변경하려고 한다.
💫 통신 시나리오 이해하고 시작하기
보영이의 DB설계에 의하면, 사용자의 선택에 대해서 다음과 같은 요청을 넘겨줘야한다.
(1) 사용자 설정 완료 후, 다음으로 넘어가는 순간
[ React 서버 측 --> fastAPI 서버 ]
[ fastAPI 서버 측 --> React 서버 ]
그러면, fastAPI 서버측에서는 history값을 프론트에게 다음과 같이 넘겨줄거다.
이게 무슨 의미이냐면, 지금부터 채팅을 하면서 진행되는 채팅은 history_id 1번으로 전달해줘라~라는 의미이다.
이제 채팅페이지로 넘어가서 채팅을 진행하게 될텐데, 프론트측은, 채팅이 진행될때마다, 서버에게 history_id 1번에 해당하는 채팅임을 알려줘야한다. 그러면 이후에 진행될 채팅에서 프론트는 채팅 정보를 fastAPI 서버가 전달해준 history번호로 전달하면 된다.
(2) 채팅을 진행하면서
[ React 서버 측 --> fastAPI 서버 ]
[ fastAPI 서버 측 --> React 서버 ]
그러면 서버측에서는 LM Studio의 응답을 받아서 프론트에게 이렇게 응답할 것이다.