개발일지

데이터 관리 방식을 변경하면서 관련 로직 수정은 모두 끝났고, 아직 MySql에서 S3로 옮기는 부분은 구현하지 못했다. 그런데 데이터 옮기는 것은 우선 데이터만 잘 쌓아놓으면 나중에 진행해도 될 것 같고, 다음주에 정식 배포하기 전에 배포 쪽 문제를 먼저 마무리해야할 것 같아서 먼저 시작하기로 했다. spring쪽은 다른 팀원이 진행하고 있고, github actions+codedeploy+nginx 조합으로 할 것 같다. nodeJS도 처음에 같은 조합으로 생각하고 github actions을 시작했는데 생각보다 자료가 없었다. 그리고 찾아보다 보니 github actions를 쓰지 않고 codedeploy+codepipeline으로 하는 것도 괜찮은 것 같아서 이렇게 시도했다. 주로 참고한 블로그 ..

데이터 부분은 수정이 끝났다! 생각보다 수정해야 하는 부분이 많았는데, 다행히 오래걸리지는 않았다. 게임 종료 후에 User와 Clue는 삭제하기로 하고, Room과 Quiz만 남기기로 했다. 그리고 Room에는 State와 Pass라는 값을 주어서, 게임이 종료되거나 게임 종료 api가 오기 전에 disconnect로 방이 사라지면 State를 CLOSE로 바꾸어서 비활성화된 정보라는 것을 표시해주고, 메인페이지에서 방을 조회할 때도 데이터가 내려가지 않도록 하였다. 그리고 나중에 S3로 데이터를 옮길 때, CLOSE된 Room과 해당 RoomId를 가지고 있는 Quiz 정보들이 그 대상이 될 것이다. 처음에는 Quiz에도 State를 만들고 게임 종료 시 업데이트를 해주려고 했는데, Room만 sta..

중간발표를 무사히 마쳤다. 지난 주 내내 중간발표때문에 조급했었는데, 다행히 잘 끝났다. 생각하지 못한 부분에서 질문을 많이 받았고, 앞으로 남은 3주 동안 어떻게 할 것인지에 대해서도 얘기해봤다. 백엔드가 비교적 기능 구현이 빨리 끝났고, 이후에 기능 추가나 성능 개선하는 부분에서 선택지가 너무 많아서 어떤 걸 해야할 지 계속 고민이 많았다. 중간발표 때 받은 피드백을 중심으로 기본적인 부분에서 미흡한 부분을 개선하기로 했고, 깃허브의 기능들도 더 적극적으로 써보기로 했다. 그리고 백엔드에서는 다음의 3가지에 초점을 맞추기로 했다. - 배포 자동화와 무중단 배포 - 테스트 코드 작성 - DB 배포 자동화와 무중단 배포는 프로젝트에 도입해보고 싶었던 기능이기도 하고, 정식 배포 전에 기능을 구현해놓으면 ..

중간발표 자료를 금요일 저녁까지 제출해야해서 오늘부터 자료를 만들기 시작했다. 화요일에 중간발표 발제가 있었고, 발표시간은 5분이라서 생각보다 짧았다. 발표내용은 프로젝트 시연, 서비스 아키텍처, 트러블 슈팅, 추후 개발 계획으로 구성되었다. 중간발표 전에도 이런 내용을 하면 되지 않을까, 생각했던 부분이라 발표자료를 구성하는 건 어렵지 않았다. 어차피 사전에 발표자료를 공유하는 걸로 알고 있어서 프로젝트 주요 기능 페이지를 추가하고, 발표 때는 생략하기로 했다. 트러블 슈팅에 어떤 걸 써야할지가 좀 고민이 됬는데 회의에서 금방 결정이 됬다. 그동안 이슈들은 팀노션에 간단하게라도 정리해뒀었는데 그게 도움이 된 것 같다. #유저의 disconnect 문제 정말정말 고민이 많았던 문제다. 이렇게(https:..

오늘은 마지막 기획멘토링이 있었다. 이번주에 중간발표가 예정되어있는만큼 오늘은 그간 진행 상황과 함께 중간발표 때 어디까지 구현이 가능한지 확인하는자리였다. 우리조는 MVP는 마무리가 된 상태이고, 마지막 기획멘토링이기 때문에 이후에 어떤 기능에 집중할지에 대해서도 간단히 정리를 해갔다. 프로젝트의 성격이 다른 조와는 많이 다르고, 사용하는 기술도 기존에 항해 실전프로젝트에서는 잘 다루지 않은 기술이라서 다른 분들도 진행상황을 궁금해하시는 것 같았다. 멘토링 때 간단히 진행 상황을 보여드렸는데 일단 괜찮은 것 같았다...! (사실 나는 좋은 반응인가 했는데, 같이 들은 분들 얘기를 들어보니 괜찮았던 것 같다!!) 나중에 포토폴리오를 만들 때 프로젝트의 설명만 들어서는 어떤 방식으로 구현을 한건지 잘 상상..

오늘 엄청난 사실을 알게되었다!!! (우리 실전프로젝트에서 WebRTC 성공에 이어 2번째 축포를 터트리는 순간인거같기도 한데 좀 다르다) 우리가 계속 고민했던 부분은 게임 방 resource의 용량이 커서 로딩에 시간이 오래걸리는 문제였다. 구입한 3D 모델링 파일이 150MB 정도라서 여기서 크게 줄어들지 않을 것으로 생각하고 로딩이 오래걸릴 때 화면에 어떤걸 보여줘야 하는지 (예를 들면, 로딩페이지에서 게임 안내나 팁 같은 간단한 텍스트를 보여준다거나), 로딩 중에 유저가 disconnect됬을 때 어떻게 해야하는지, 모든 클라이언트가 로딩이 완료된 걸 어떻게 처리할지 고민했었다. 그런데 정작 게임 방 resource를 export하니 용량이 2MB였다....!!! 우리가 걱정했던 많은 문제들을 단..

새로운 quiz를 만들면서 imgUrl이 추가되었다. 퀴즈 유형마다 필요한 column이 달라서 RDB에서는 어떻게 스키마를 잡아야 할지 고민이 된다. 현재는 필요한 column을 모두 넣어놓고 값이 없는 column은 null이 저장될 수 있게 지정해놓은 상태이다. 만약에 noSQL을 쓴다고 하면 저장은 스키마 상관없이 자유롭게 할 수 있을 것 같은데, 클라이언트에 데이터를 내려줄때는 어떤 형태로 내려주는게 좋을지 고민이 될 것 같다. (퀴즈마다 아에 다르게 내려주거나, 아니면 지금처럼 모든 걸 포함하는 dto를 만들어서 해당되는 값이 없으면 null을 넣어주거나....?) noSQL은 SQL과는 많이 다른 것 같아서 사실 어떤 식으로 구성될지 잘 이해가 안간다. Rank 쪽에서도 수정이 있었다. Ra..

로그인은 없고, 게임할 때만 임의로 방과 유저를 만든 후에 이를 모두 삭제하지만 게임 결과는 별도로 저장해서 보여주기로 했다. 메인페이지에서 게임 순위를 보여주는 부분이 있고, 게임 종료 후에는 해당 팀의 결과 포함 위아래 2개씩 해서 총 5개만 보여주기로 했다. 전체 Rank를 보여주는 api는 이미 작성한 상태고, rankList를 가져오고 나면 Dto에 넣는 과정은 비슷하기 때문에 RankService의 같은 로직을 조금만 수정해서 그대로 사용하고 싶었다. 먼저 매개변수가 있고, 없는 차이가 있었는데 이거는 Controller에서 임의값을 넣어주기로 했다. // 전체 랭킹 조회하기 @GetMapping("/ranks") public List getRanks() { Long roomId = -1L; ..

현재 퀴즈는 같은 문제가 나오지 않도록 문제 유형만 통일하고 변수들의 값을 변화를 줘서 다른 답을 제출하도록 구성해놓았다. 그런데 문득 다른 팀원 분이 이렇게 하면 문제를 클릭할 때마다 달라진다는 사실을 캐치하셨다...!! 적어도 같은 방에서는 누가 클릭해도 같은 문제를 보이게 해서, 처음 우리의 의도대로 같이 문제를 풀 수 있게 구상하기로 했다. 현재 퀴즈는 단서 없이 해당 문제만으로 답을 찾을 수 있는 A타입과, 단서가 다른 오브젝트에 있어서 단서를 찾아서 조합해 풀어야 하는 B타입이 있다. A타입은 별도로 Quiz entity를 만들어서 퀴즈를 조회할 때 저장된 값이 없으면 새로 만들어서 저장하고, 그 이후에는 db에 저장된 값을 불러오도록 하였다. B타입의 경우 현재 Room entity 안에 c..

유저의 로딩 완료 문제를 처리하다가, 로딩 중에 연결이 끊기면 어떻게 되지? 라는 질문이 나왔다. 기본적으로 클라이언트가 방에 들어오면 socket통신으로 연결되기 때문에, 연결이 끊기면 socket.io에서 가장 먼저 알게된다. 문제는 이렇게 연결이 끊긴 것을 spring 서버에서 알고 db에서 처리를 해줘야 한다는 점이다. 메인페이지에서 방 리스트를 조회할 때 방의 인원수도 같이 표시되기 때문에 업데이트를 해줘야 한다. 그래서 처음에 고민했던 것은 node에서 spring으로 바로 socket.id를 알려주는 것이다. socket의 disconnect 이벤트 안에서 spring으로 데이터를 보내줘야 하는데 socket 통신에서 HTTP 통신을 쓸 수 있는지 알 수 없었다.(불가능하지 않을까?) 서버 ..