[제안] 팔로우, 언팔로우시 GitHub 연동을 이벤트 발행 방식으로 변경한다.

[xlffm3]

작업 내용

• 팔로우 / 언팔로우시 트랜잭션 내부에서 source.follow(traget) 과 같은 코드 호출 이후, GitHub 서비스에 API 콜을 보내 GitHub 계정도 팔로우합니다.
• 우리 서비스 로직 대부분의 경우 GitHub API로부터 전달 받은 데이터를 가공해서 응답을 반환하는데, 이 경우는 api 콜 이후 특별히 데이터를 가공하지 않습니다.
• 따라서 트랜잭션이 커밋되는 시점에 이벤트를 핸들링하도록 이벤트를 발행해도 괜찮을것같습니다.

---

다만 생각해볼 여지는 있을 것 같습니다.

일반적으로 회원가입 이후 가입 축하 메일 발송과 같은 부분은 트랜잭션 내부에서 처리하기보다는, 이벤트 발행을 통해 처리하는게 괜찮아보입니다.
왜냐하면 트랜잭션의 주된 목적이 회원가입인만큼, 메일 서버 속도로 인해 트랜잭션 처리 속도가 하향되거나 메일 발송 실패로 트랜잭션이 롤백되는건 조금 문제가 있기 때문입니다.

우리 서비스에서 '팔로우/언팔로우시 깃헙 팔로우/언팔로우를 하는데, 만약 깃헙 서버 오류로 깃헙 팔로우/언팔로우가 실패하면 트랜잭션을 롤백할 것인가?'에 대한 논의가 있어야겠네요.

1. pickgit 사용자가 팔로우/언팔로우 누르면서 동시에 깃헙 팔로우/언팔로우 하는것은, 깃헙 팔로우/언팔로우 기능이 주된 관심사인만큼 깃헙 서버상에서 팔로우/언팔 실패시 트랜잭션 롤백되는게 맞다.
2. 아니다. pickgit 서비스상의 팔로우/언팔로우 자체가 중요하다. 깃헙 연동 팔로우/언팔로우는 편의를 위한 부수적인 기능일뿐, 트랜잭션에 포함될 필요가 없다. 되려 깃헙 서버 느려지면 팔로우/언팔로우가 오래 걸린다.

주의사항

[bperhaps]

좋습니다. 몰랐는데 이번에 공부하면서 트랜잭션 내부에서 외부 API와의 네트워크 통신이 db connection에 미치는 영향에 대하여 알았습니다.
트랜잭션이 유진된다는것은 결국 db connection을 유지한다는것과 동일하기때문에 github 와의 통신에서 발생하는 network overhead로 인해 전체적인 시스템의 성능에 영향이 크게 미칠것으로 예상됩니다. 그래서 일반적으로 트랜잭션 내부에서 외부 API를 호출하지 않는다고 합니다.
따라서 위 의견에 동일합니다. Spring Data JPA 이벤트 기능 어디서 쓸까 했더니 이렇게 쓰게될 기회가 생길줄은 몰랐네요

깃헙 팔로/언팔로같은 경우는 저는 롤백을 해주는게 좋다고 생각하기는 하는데, 그렇게되면 결국 트랜잭션 내부에서 github와의 connection을 유지해야하는 문제점이 그대로 있겠네요. event발생하고 실패했을때 분기를 delete or update 쿼리를 날려주는 방식으로 처리하는건 어떠신가요?