Feat: Like opinion - Githubissues

Binsk-dev commented 1 year ago

해당 PR은 #60 을 해결하기 위한 PR입니다.

전제조건

해당 기능은 @Jaewook-Lee 님이 만드신 initJoin 액션을 무사히 수행한 뒤에 실행하는 것을 가정합니다.

Request Form

{
    "action": "like",
    "userId": "<유저 ID>",
    "round": <현재 라운드>,
    "opinionNo": <해당 의견 order>
}

Response Form

{
    "action": "likeResult",
    "result": "success",
    "opinionNo": <해당 의견 order>,
    "noOfLikes": <이번 좋아요가 반영된 전체 좋아요수>
}

고민거리 및 주의사항

해당 기능의 경우 현재 refresh 타임 때, 일괄적으로 프론트에서 호출된다고 가정하고 작성하였습니다. 그러나 저번 회의에서 Opinion 상태를 바꾸는 별도의 람다 함수가 time을 기준으로 계속 실행되고 있다고 했기 때문에 실시간으로 이 기능을 호출 가능하게끔 바꾸는게 더 좋을지 살짝 고민입니다. -> 만약 실시간이 된다면 unlike 기능도 추가되어야 합니다.
Like 기능은 위에서 말한 호출 시점과 관계 없이 유저 간에 경쟁 조건이 발생할 수 있습니다. 따라서 동기화를 시키는 코드를 적용했습니다만, 시나리오 테스트에 대해서는 검증이 되질 않았습니다. 해당 부분에 대해서는 테스트를 해주시고 피드백을 해주시면 좋을 것 같습니다.

Jaewook-Lee commented 1 year ago

like 액션이 정상적으로 수행되는 것을 확인했습니다.

현재 PR이 master branch에 병합하기를 요청하고 있습니다. dev branch로 병합합시다.
동기화가 제대로 되는지 확인해보고 싶지만 이를 명확히 확인할 방법이 전 생각이 나지 않네요 ^^;
어떻게 동기화를 테스트 할 수 있는지 다른 분들의 조언 부탁해요!

seungholee-dev commented 1 year ago

액션 확인했습니다!

조사를 해보니깐 Like 수를 +1 업데이트 하기 전에 기존의 Like 수를 Select해서 먼저 가져온 다음에 WHERE 문으로 WHERE LIKE=(이전 카운트 수)로 확인을 해서 겹치지 않게하는 방법이 있는 것 같아요. 만약 에러가 생겨서 해당 쿼리가 적용이 안된다면 쿼리를 다시 날려주는 방법이 떠오르는데 최적의 방법인지는 의문이네용 흠...

https://stackoverflow.com/questions/129329/optimistic-vs-pessimistic-locking 이 부분에서 Optimistic locking부분을 참조했습니다.

Binsk-dev commented 1 year ago

쿼리를 다시 날려주는 방식은 지금 사용하는 FOR UPDATE문 방식이 동작하지 않을 경우 사용하도록 하겠습니다. 그럼 지금 방식을 일단 채택하도록 하고 Approve 해주시면 현재 버전으로 merge 진행하겠습니다.

seungholee-dev commented 1 year ago

해당 기능은 구현하게 되면 추후에 새로운 PR로 여는게 어떤가요?! 우선은 기능에 초점을 맞춰서 Approve와 Merge 진행했습니다!
고생하셨어요!

kookmin-sw / capstone-2023-05

Feat: Like opinion #63