Conversation
munwalk
left a comment
There was a problem hiding this comment.
3주차 과제 수고하셨습니다!
API 설계 사고 과정을 문서화하신 점이 정말 인상적입니다! 엔드포인트 명명 규칙, HTTP 메소드 선택 기준, 인증 유무 판단 기준까지 작성하셔서 왜 이렇게 설계했는지가 명확하게 보입니다. 특히 커서 기반 페이징(lastDeadline, lastId)을 홈 화면에 적용하신 점이 2주차 학습 내용을 잘 반영하셨네요!
Response Body와 에러 처리까지 상세하게 작성하셔서 실제 개발할 때 바로 참고할 수 있을 정도로 완성도가 높습니다. 통일된 응답 형식(success, code, message, data)과 에러 코드 체계(E4001, E4002 등)도 체계적이고, /api/v1/stores/{storeId}/reviews처럼 리소스 기준으로 RESTful하게 설계하신 점도 좋습니다!
다만, 진행중/완료 미션 조회 API에서 페이징 처리(page, size 또는 커서)가 없는데, 미션이 많아지면 성능 문제가 생길 수 있으니 추가하면 더 좋을 것 같습니다!
수고하셨습니다!
munwalk
left a comment
There was a problem hiding this comment.
2주차 과제 수고하셨습니다!
데이터베이스 정규화, 인덱스, ORM vs Raw SQL 키워드를 상세하게 정리하셨네요! 특히 N+1 문제까지 추가로 학습하고 Fetch Join, Entity Graph, Batch Size 해결책까지 작성하신 점이 인상적입니다.
쿼리 빌딩 순서를 체계적으로 문서화하신 점이 정말 훌륭합니다! "누가 주인공인가(FROM) → 누구의 도움이 필요한가(JOIN) → 누구꺼, 어떤 것만 볼 것인가(WHERE) → 어떤 순서로(ORDER BY) → 화면에 뭘 내보낼까(SELECT)" 순서로 사고 과정을 단계별로 작성하셔서 쿼리 설계 로직이 명확하게 보입니다!
Cursor based 페이징도 정확하게 구현하셨고, 플레이스홀더(:memberId) 개념까지 설명하신 점도 좋습니다. 리뷰 작성 쿼리에서 사장님 답글 기능을 추가하기 위해 parent_id를 활용한 자기 참조 구조를 설계하셨고, 사장/고객 공용 동적 조회 쿼리에서 CASE WHEN으로 역할별 정렬을 분기 처리하신 점도 실제 서비스에 필요한 기능을 잘 구현하셨습니다!
1주차 ERD도 피드백 반영해서 수정하셨네요. member 테이블에 role 컬럼 추가, store 테이블에 member_id 추가, review 테이블에 parent_id 추가, 그리고 1주차에 지적받았던 불필요한 region_id, category_id도 제거하셨습니다!
홈 화면 쿼리를 상단/하단으로 분리한 것도 좋고, "마감 기한 정렬 시 UX를 어떻게 개선할까?"까지 고민하신 흔적도 보입니다. 커서 vs 오프셋 페이징 선택 기준과 카테고리 필터 추가 아이디어까지 작성하셨네요!
수고하셨습니다!
No description provided.