일단 아는 동생과 함께하는 토이프로젝트인데, 비밀일기를 만들고 싶다고 해서 그렇게 만들 것 같다.
졸작 서버단 구축좀해줘 / 그래
왜 비밀일기?
개인적으로 토이프로젝트에서 트래픽 을 좀 느껴보고 싶다! 라고 하면 트위터에 배포하는 것이 제일 효율적이다.
왜냐하면 트위터는 동시접속 사용자가 상당히 많고 RT(리트윗)이 될 경우 순식간에 홍보를 할 수 있다.
그러다보니 간단하게 로그인을 해서 사용할 수 있는 것을 찾다보니, 일기가 나오지 않았나 싶다 ㅋㅋ
받은 기획서 개요
급하게 쓴거라 부끄럽다길래 개요만 허락받고 올린다.
물론 수많은 페이지가 있는건 아니고 세개정도 더있음
구성
받은 기획서로는 내가 생각한거랑 상당히 다르길래 물어보려고 했는데...?
일어나
그래서 일어나서 이제 의견 정리를 좀 했다....^^...
페이지의 구성
어 쓰려고 생각정리하니 뭔가 이상한데
- 메인 페이지
메인페이지에서는 단체 다이어리에 참가하거나, 다이어리를 생성할 수 있다.
회원가입 페이지로 이동할 수 있다.
- 다이어리를 참가할 경우에는 생성 코드와 생성자가 지정한 비밀번호를 쳐야 참가할 수 있다.
- 다이어리를 생성할 경우에는 다이어리의 이름, 비밀번호를 누른 후 생성하기 버튼을 누르면 생성할 수 있다.
- 회원가입 페이지
회원가입은 간단하게 트위터 로그인 혹은 구글 로그인을 활용하거나, 인증없이 아이디 비밀번호로 진행될 수도 있다.
핸드폰 인증을 넣고 싶긴한데, 이것은 사용자에게 접근성이 떨어진다는 생각이 들어서 고려만 해보고 있다.
아님 이메일 인증이라도 넣던지.... 아니 둘다 불편한거같은데
로그인 절차는 최대한 간단하고 쉽게 지원하려고 한다.
- 다이어리 페이지
다이어리 페이지에서는 자신만의 일기를 작성할 수 있고, 다른 사람의 일기에 좋아요를 누를 수 있다.
또한 댓글을 달거나 수정 삭제 기능이 포함되어있다.
- 일기를 작성할 경우 로그인을 한 상태라면 제목과 내용만 작성하면 새로운 일기가 생성된다.
- 비로그인 상태일 경우 아이디와 비밀번호를 입력한 후 제목과 내용을 작성해야만 일기가 생성된다.
- 비로그인 상태의 유저는 좋아요를 누를 수 있는 권한이 없다.
- 로그인을 한 유저는 댓글을 작성할 수 있고, 자신이 쓴 댓글에 한하여 수정, 삭제가 가능하다.
- 비로그인 상태의 유저는 댓글을 작성하기 위해서는 아이디,비밀번호를 입력해야만 하며 수정, 삭제를 위해서는 아이디 비밀번호를 동일하게 적어야한다.
- 해당 다이어리에서 탈퇴(?)를 할 수 있는 버튼이 있으며, 경고를 보여준 후 탈퇴가 가능하다.
이것은 로그인을 한 유저에 한해서만 보여진다.
- 마이 페이지
마이페이지에서는 자신이 참가한 다이어리에 대하여 확인을 할 수 있고 새로운 글이 올라왔는지, 자신이 작성한 일기에 댓글, 좋아요 등이 달렸는지 타임라인처럼 확인을 할 수 있다.
(실시간 지원은 시도는 해보겠지만 가능할지는 모르겠다.)
- 회원 정보 수정 및 탈퇴가 가능하다.
- 자신이 작성한 일기에 대한 피드백을 볼 수 있는 탭이 존재한다.
- 자신이 참가해있는 다이어리를 확인할 수 있으며 해당 다이어리에서 탈퇴할 수 있는 버튼이 있다.
대충 구성은 이렇게 4개로 진행이 될 예정이다.
고민하고 있는 부분
그런데 여기서 몇가지 의문이 든다.
일단 로그인에 대한 의문이 있다.
- 방을 생성하면 맨 처음에 들어갈 때는 비밀번호를 입력해야한다.
- 근데 이 서비스를 이용하기 위해서는 회원가입을 하는 것이 편리하다.
이러면 결국 2개의 로그인이 필요한 서비스가 되는데....
접근성이 너ㅓㅓㅓㅓㅓㅓㅓㅓ무 떨어져서 이 부분에 대해서는 많은 논의를 해봐야할 것 같다;
그리고 생성코드에 대한 문제도 있다고 생각한다.
나는 그냥 URL을 직접적으로 던져주고 그거에 비밀번호를 달아서 쓰려고했는데?
URL = ROOM 테이블의 PK = 엔드포인트
이건 아닌 것 같아서 디스코드마냥 생성코드를 발급해주는 식으로 해야할 것 같다.
이러면 사실상 축약 URL 비스무레한 기능을 구현하는 셈인데(ㅋㅋ)
아마 이 부분을 레디스로 만들던가 해야할 것 같다;
난 NoSQL 써보고 싶었는데
이거 사용할 수 있나 싶다 진짜..
왜냐하면 업데이트요소가 너무 많다
룸(다이어리) : 멤버 들어올 떄 마다 수정함
회원정보 : 수정가능
일기 : 수정가능
댓글 : 수정가능
=> NoSQL을 사용하지 말아야할 때가 바로 수정요소가 많을 때 인데
이건 뭐 그냥 죽어라 수정만 해서 NoSQL을 사용하는 것은 무리가 아닐까 싶다...^^...
사용 예정 스택
프론트는 아직 더 이야기를 해봐야할 것 같고
나만 이야기를 하면
NestJS, GraphQL, MySQL, TypeORM, Redis, GCP정도 쓰려나
몽고디비를 쓰려고 노력은 해보겠지만 너무 효율이 떨어질 것이라 생각해서 고민중이다.
회의
일어났길래 한 두시간정도 수다를 떨고(?) 어느정도 정리를 했다.
Y = 나
S = 동생
- 로그인 기능은 빼야한다. 기획서에 번거로운 계정공유라는 큰 틀이 있으니 빼자!
- Y : 그럼 룸 관리 권한은 누구한테 줘야하는데?
- S : 그냥 전원한테 다 주면 되지 않아? 어짜피 친구들이랑 쓰는건데
- Y : 해킹을 당했다고 치자, 그럼 다 날라가는데?
- S : 보안교수님 죄송해요.,,.. 제가 열심히 공부했는데...
- Y : 룸 생성할 때 관리자 비밀번호, 참여자 비밀번호 2개를 입력하면 어느정도 해결이 될 것 같은데?
- S : 그거 좋네 그렇게 하면 다 해결되겠다
- 일기에 접근하는 방식은 어떻게 할까?
- Y : 참여코드 + 비밀번호로 입력을 하는 것은 그대로 가지만, 참여코드가 URL이면 안될 것 같다.
- S : 그거 내가(프론트) 해결할 수 있음 걱정 ㄴㄴ
- Y : 그래도 바로 보여지는 것은 아닌 것 같으니까 디스코드처럼 따로 빼서 관리하는걸로
- 피그마보면 룸에 사진이랑 제목이랑 사용자수같은거 있던데 구현 가능??
- Y : IP로 따면 될 것 같은데... 근데 그럼 다른 위치에서 접속하면 여러개가 된단말이지?
- S : 줌도 한 계정으로 폰이랑 컴으로 접속하면 두개 뜨는데?
- Y : 대기업도 하는데 우리라곤 못하나 그렇게 ㄱㄱ
- 좋아요 눌렀을 때 상태값 유지시키는거 구현할 수 있나?
- S : 개쉬움
- Y : 멋져
- 이미지가 들어가면 좋을 것 같은데 이거 어떻게 할까
- Y : 해달라면 다 해줄 수 있긴 한데 있으면 좋지 않을까?
- S : 있으면 당연히 좋지... 근데 UI/UX랑 디자인을 다 해야하는데 어떻게 해야할지 잘 모르겠네
- Y : 그럼 일단 고려를 해보자 있는게 좋긴 해
- S : ㅇㅇ.. 있는게 좋긴해
- 캘린더 넣으면 어때?
- S : 나 죽어
- Y : 근데 이게 이직할 때 쓸 수 있는 프로젝트처럼 생각든단말이지
- S : 그것도 그렇긴 해....
- Y : go?
- S : 여유있으면 해볼게,,,,
이정도로 대화가 끝나서 바로 디비설계를 했다.
DB 설계
모조리 다 수정이 계속 있어서 NoSQL은 진짜 No인 것 같다
다음에 써야지
