채팅은 어떻게 구현할지에 대해 논의 해보셨나요!? api 명세를 보니 채팅 보내기 api만 있는데 해당 api를 통해 채팅 내용을 DB에 저장한다하면 상대방이 채팅내용을 받은 것을 어떻게 인지할 것인지? 에 대해 고민해보셔야 될 것 같습니다. ex) 웹소켓을 사용하거나 http polling 방식을 사용해 채팅상대방이 이를 인지할 수 있어야함
노션을 통해 유스케이스 등은 자세히 적혀있으나 해당 기능을 어떻게 구현할 것인지에 대해 자세하게 나와있는 곳이 아쉽습니다. 1번에서 채팅을 어떤식을 구현할지에 대해 여쭤본것과 동일한 맥락입니다
ERD 연관관계 설정은 좋아보입니다. 아쉬운점은 User 테이블에서 userId 대신 id만 적어도 유저의 아이디라는 것을 알 수 있습니다.
api 명세에서 복수형으로 써주신 것은 좋은데 계층형으로 적용되어있지 않아서 아쉽습니다. ex) 유저팔로워 목록확인 /v1/users/follower/{id} -> /v1/users/{userId}/followers 어떠한 유저에 대한 팔로워 목록 확인이기 때문에 뒤에 적는 것이 보편적인 restful api 원칙에 맞습니다.
로그인 방식은 세션방식을 쓸것인지 토큰방식을 쓸것인지 해당 값들을 어떠한 저장소에 저장할 것인지도 문서에 작성되어있으면 좋을 것 같습니다. 또한 면접때 매우 자주나오는 질문이기 때문에 세션,토큰 방식의 장단점과 왜 이기술을 선택했는지에 대해 정확한 논리가 있으면 좋을 것 같습니다.
모집글이 엄청 많아지게 된다면 (몇억개) 모집글 전체 조회 API를 통해 가져올 수 있을까요? 성능을 못버티지 않을까요? 이를 해결하려면 어떻게 해야할까요?
모집글 좋아요 api 명세도 /v1/posts/like 로 되어있는데 restful api에 맞게 설계된게 맞을까요? 어떤글에 대한 좋아요라면 다른 url을 사용하는게 맞을 것 같네요
어떤 모집글에 좋아요 개수가 몇천만개가 된다면 지금처럼 연관관계를 통해서 나타내면 성능에 문제가 생기지 않을까요? 이를 해결하려면 어떻게 해야할까요?
모집글 기술스택은 테이블이 꼭 분리되어야 할까요?
모집글 좋아요와 같이 다른테이블의 pk가 두 개가 있는 연관관계 테이블들은 조회할 때 쿼리가 어떻게 나갈까요?
장점: