채널 생성 방식 개선

[devphilip21]

채널 코드 생성

기존에 논의한 내용 #3

채널 생성에 대한 트랜잭션 보장 문제

현재 서버를 트래픽으로인한 장애 발생 가능성에 따라서 물리적으로 분리했는데, 이 분리의 기준을 잘못 잡았다는 생각이 듭니다.

현재 채널 생성의 프로세스는 다음과 같습니다.

1. 클라이언트에서 채널 ID 생성
2. 생성된 채널 ID 를 통해 컨버터 서버로 요청
   (클라이언트에서 Rest 요청으로 슬라이드 포맷을 이미지로 변환하여 S3에 올리는 헤비한 작업)
3. 채널 ID 와 기타 데이터를 통해 채널에 대한 정보를 생성
   (클라이언트에서 GraphQL 요청으로 DB에 저장)
4. 채널생성 완료 응답

즉, 2번 프로세스까지 성공하고 3번 프로세스가 실패하면, 전체 채널생성 트랜잭션이 롤백 되어야하는데 거기에 대한 처리가 되어있지 않습니다.

그리고 현재 구조에서 이는 구현이 상당히 까다로워 보입니다.
따라서, DB에 채널 정보를 생성하는 것 또한 컨버터 서버에서 하는 것이 합당해보입니다.

소스코드의 중복

현재 클라이언트 쪽 소스에서, 채널생성에 대한 동일한 코드가 드래그앤 드랍으로 생성할 때와, input 을 통해 생성할 때 각각에 삽입되어있습니다.

이 부분을 공통화해서 관리해야할 것으로 보입니다.

프로그레스 개선

현재 프로그레스를 폴링 방식(요청을 재귀적으로 하는 방식)으로 구현했는데, 컨버팅 시간이 굉장히 긴 슬라이드의 경우 커넥션이 프로그레스 도중 끊어지면서, 제대로 응답이 이뤄지고 있지 않은 이슈가 있습니다. 결국 소켓 통신을 활용하는 것이 좋아보입니다. socket.io 활용 추천