2월7일 피드백 내용
- 참여인원제한기능(게시글 동시성문제) 트랜잭션과 관련있음.
-> 참여신청 후 주최자가 승인하는 식으로 해결.
- 게시글에 봉사활동횟수 봉사활동시간 넣을 것.
- ERD 게시판에 전체 게시글 조회 페이징 리퀘스트 ~~
~~- 관심지역게시글 조회 /search posts/search 로 변경
- 게시글에서 local varchar -> enum type으로(코드는 이넘타입)
- 일반운영서비스 관점에서 이넘이란 타입은 항상 변경이 될 여지가 있다는 의미. db에 이넘으로 넣게되면 코드도 수정해야하고 데이터베이스도 수정
해야한다. DataBase를 varchar로 하면 코드단만 수정하면되서 관리가 용이하다.
데이터베이스는 varchar 코드는 enum
이미지처리 방법
1 데이터베이스 자체에다가 이미지를 바이너리 형태로 저장하는 법
2. 이미지를 특정 클라우드 저장소에 업로드를 해서 업로드한 이미지 링크값을 디비에 저장하는 형태.(AWS S3사용) -> AWS S3 사용하기로 함.
API명세서 피드백
- API —> 페이징 관련한 정보 리퀘스트에 나타내야 함
- 프로필작성 /profiles로 해도 됨
- 마이페이지 -> 리퀘스트 데이터로 프로필아이디/유저아이디 등의 정보가 넘어가야 누군지 알 수 있음
/profiles/{profile_id}
- 나의 봉사활동 보기 -> 리퀘스트 정보가 없음. (참여횟수, 참여시간)
- 게시글 이름을 봉사관련 네이밍으로 변경하기-> Post -> VolunteerWorkPost로 변경
- admin 게시글에서 /admin 빼는게 나을 듯 관리자도 그냥 일반유저꺼 사용 토큰값으로 구분짓기
- 공지사항 작성 -> 테이블 분리 하던가 이넘타입으로 구분할 것
- 신고받은 유저 활동정지 /admins빼고 /users/{users}/black-list로 변경
- 인증서발급 -> 추가 구현 기능으로 변경
- 댓글작성 커멘트 아이디 뺄것
- 댓글수정 유저아이디 왜 필요한가?
- 신고하기 reports 빼고 뒤로
- 신고한 유저정보를 관리자 페이지에서 볼 수 있게끔
- 마이페이지 —> 리퀘스트에 누구의 정보를 가져올지를 넣어줘야 함 -> 삭제
- 지역 —> varcha로 돼 있는데 이넘 타입으로 관리하는 게 맞다. 테이블에서는 바차로 해도 되는데 코드부분에서는 이넘타입으로 관리돼야 함.
- 신고 —> 해당 게시글의 신고 횟수 노출해주거나? 그런 거 아니면 굳이 테이블을 따로 만들지말고 enum이나 column으로 넣는 게 더 나을 것 같다. // 관리자 페이지에서 블랙리스트를 확인할 수 있는 걸 해주는 게 좋을 것 같다..
프론트 구성 문제
백엔드 큰틀만 우선 구성 -> 동기/비동기 선택->동기 소통과 데이터를 어떻게 사용하냐 차이 -> 부트스트랩 사용 .클래스명 겹치지 않게 사용.
