과제 피드백

[lookatmina]

안녕하세요. 피드백을 담당하게 된 윤민아 튜터입니다. 과제를 진행하시느라 너무너무 고생하셨습니다! 👏👏👏

전반적인 피드백

• API 명세서와 erd는 추후에라도 추가해주세요!
• 개발할 때 확인을 위해 찍었던 console.log는 지워주세요! 일부러 로깅을 위해 남긴 게 아니라면 필요한 정보를 보려고 할 때 지장을 줄 수 있습니다~
• try catch를 사용해서 에러 핸들링을 해주세요! 한 곳도 있고 안 한 곳도 있는데 일관성있게 처리해주시면 좋겠습니다!
• test를 작성해주신 점이 좋습니다. 로그인만 테스트하는데 db가 비어있는 경우를 생각해서 회원가입 후 로그인을 테스트하도록 작성하면 더 좋을 것 같아요!!
• 전반적으로 기능은 의도한대로 구현했지만 디테일한 요구사항 맞추기가 조금 아쉽습니다! 스스로 뭔가를 만들 때는 상관없지만 요구사항이 주어진 경우에는 요구사항을 맞추는 게 최우선이라는 점!! 잊지 말아주세요!

구현 사항에 대한 피드백

• [x] 회원가입 api
  • joi를 사용해 parameter validation하는 부분이 좋습니다.
  • 요구사항에서 이름, 비밀번호 확인을 받도록 되어있습니다. id가 이름을 뜻하는 거라면 name이 조금 더 어울릴 것 같아요. 근데 id가 unique로 되어 있는 걸 보면 이름은 또 아닌 것 같고.. 그렇습니다. 설명이나 추론이 필요한 코드보다는 명확하고 자세하게 써주는 코드가 남들이 읽기 편합니다!
  • userInfo테이블이 따로 있는데 회원가입할 때 해당 테이블은 사용 안하시나요? 우선 스키마를 봤을 때 user테이블과 칼럼이 중복됩니다. 이 부분은 제거해주시면 좋을 것 가타요.
  • try catch로 잡은 error는 500코드가 조금 더 적절할 것 같고 나머지 에러는 http 상태코드를 추가해주세요! 그리고 catch에서 response를 보내지 않고 있어요. 확인해주세요!
• [x] 로그인 api
  • get method에서 body를 받는 것은 일반적이지 않습니다. method를 post로 바꾸는 것이 적절할 것 같아요.
  • parameter validation 없음
  • 요구사항은 이메일과 비밀번호로 로그인하는 것입니다!
• [ ] 내 정보 조회 api
  • 인증 미들웨어를 통해서 동작하도록 바꿔보세요!
  • 회원가입 시 userInfo에 뭔가를 저장하지 않고, 여기서 get하려는 것은 부자연스럽습니다.
  • specificInfo가 null인 경우 응답을 받을 수 없습니다. 처리가 필요합니다.
• [x] 인증 미들웨어
  • 토큰이 없거나 있어도 토큰이 유효하지 않을 때, 만료되었을 때를 구분해서 에러처리 해보세요!
  • 쿠키에서 정보를 가져올 때 저런 방식으로 가져오면 원하는대로 동작하지 않을 수 있습니다. cookie의 원하는 키를 지정해서 가져올 수 있습니다. cookieParser를 사용하고 있다는 것을 떠올려보세요~
• [x] 이력서 작성 api
  • url이 POST /resumes 가 조금 더 일반적일 것 같아요. resume router 내에서 다른 api들과 통일성을 유지하는 것이 좋습니다. (상세조회,수정,삭제 전부 /resumes/:resumeId 형식이 일반적입니다!)
  • 요구사항에 최초 등록시에는 항상 APPLY로 되어있으니, status를 받지 않고 default값을 주면 될 것 같아요.
  • 저라면 newResume를 select하기 전에 parameter 에러처리를 할 것 같아요! 불필요한 db 접근을 막을 수 있습니다.
• [ ] 모든 이력서 조회 api
  • 정렬을 위한 queryString의 요구사항 이해에 혼동이 있었던 것으로 보입니다. orderKey는 정렬을 하려는 기준을 의미합니다.
  • resumeList는 orderKey의 값으로 userId를 지정해서 가져오는데 response message는 인증 미들웨어를 탄 현재 이 api를 호출한 유저를 가리킵니다. 의미가 맞지 않는 결과가 도출될 수 있습니다.
• [ ] 상세 이력서 조회 api
  • 요구사항을 보면 인증 미들웨어를 타지 않아도 조회가 되어야 합니다.
  • response의 message가 명확하지 않습니다. resumeId가 3이라면 제가 한개의 이력서만 작성해도 누구의 3번 이력서라고 나올텐데 사용자입장에서는 제 이력서 중에 3번째 이력서 라는 의미로 혼동될 수 있습니다.
  • user와 join하여 작성자 이름이 response에 포함되어야 합니다.
• [x] 이력서 수정 api
  • 조금 더 명확한 코드를 작성하려면 update를 바로 진행하는 것보다는 select로 먼저 존재여부, userId 일치여부를 확인한 후에 update를 진행하는 것이 좋습니다. db에 접근하는 횟수을 줄이려는 의도였을 것 같은데 리소스가 존재하지 않아서 수정을 할 수 없는 건지, 권한이 없어서 수정을 할 수 없는 건지 구분을 해주는 것이 더 중요할 수 있습니다!
  • status 수정이 가능해야 하고, status에 대한 검증도 필요합니다.
• [x] 이력서 삭제 api
  • 수정이랑 똑같이 바로 delete하는 것보다는 select 후에 진행하시면 좋을 것 같아요!

[lyukidon]

Readme 작성 완료 했습니다.

• [x] 서버 location
• [x] ERD
• [x] API 명세서

변경

• users id -> users username
• 로그인 api
  • [x] validator추가
  • [x] email로 로그인
• 내 정보 조회
  • [ ] 인증 미들웨어를 통해 동작
• 인증 미들웨어
  • [x] 토큰이 유효하지 않을 때, 만료되었을 때 에러처리
  • [x] cookieParser 이용해, 원하는 값을 가져오기
• 이력서 작성
  • [x] POST /resumes 로 변경
  • [x] database 접근 전, parameter 에러 처리
  • [x] status 받지 않고 default 값
• 모든 이력서 조회
  • [x] orderKey resumeId status
• 상세 이력서 조회
  • [x] response 메세지 수정
  • [ ] users와 resumes join 하여 확인
• 이력서 수정
  • [x] update 전, find로 데이터 존재 여부 확인 후 진행
  • [x] status 수정 가능
  • [x] validator 추가
• 이력서 삭제
  • [x] find로 데이터 존재 여부 확인 후 delete

[lookatmina]

추가 피드백

• api 명세서 type 명시 필요

  • request 보낼 때 password가 string인지 number인지 명시되어야 합니다!
  • response도 명시하면 좋지만 힘들다면 예시 데이터라도,,!

• api 명세서와 코드 내용이 다름..! 명세서는 id로 되어있고 코드는 username으로 되어있음

• 회원가입 catch에서 response를 보내지 않고 있어요. return res.status(400) 이렇게하고 끝내면 status code만 세팅하고 response를 안 보내요!

• 회원가입 email로 중복검사만 하는데 username도 중복되면 안되는 건가요?

  • email로 중복되는 유저가 있으면 email이 중복이라고 알려주면 되는데
  • username이 중복되는지 확인하려면 username으로 다시 select하셔야 하지 않을까요!?

  • 둘 다 확인하고 싶으면 이런 식으로 하는거지 email이 같은 유저의 username을 확인 하는 건 약간 흐름이 이해가 되질 않아요!! 어떤 걸 원하시는지?

    const emailDuplicated = ... findFirst({email})
    const usernameDuplicated = ... findFirst({username})
    
    if(emailDuplicated && usernameDuplicated) {} ... // 여기서 나누기

• 내정보조회, pw 노출됨

• 이력서 생성, status값이 들어오면 APPLY default가 안됩니다. (요구사항)

• 이력서 목록/상세 조회시 user와 join해서 작성자 이름 보이게 하기 (요구사항)

• 틀린 건 아니지만 목록조회 시에는 없으면 error보단 빈 배열[]을 돌려주기도 합니다. (참고)

• 이력서 상세조회 auth 빼기 resumeId로만 조회하시면 됩니다. (요구사항)

• auth가 있다는 가정하에 resume(리소스가없는건지) user(권한이없는건지) error는 구분해주는 게 좋아요.

• 이력서 수정api tilte, content 꼭 required일까요.

• 사소하지만 resume delete하고 deleteUser라는 변수명은 안 어울리는 것 같아요.

• redis router는 확인용으로 만드셨겠지만 post면 body로 내용을 받아주시는 게 좋을 것 같아요.

• url도..! 만들거면 신경써서..!! 만들기..! 힘들겠지만요..! 그렇지만 잘 되니까 넘넘 고생많으셨습니다!

• refresh token 관련한 api도 잘 만드셨습니다. good

• kakao는 그냥 코드만 봤는데요 redirect_uri 부분을 잘 써주셔야 로컬에서도 배포한 서버에서도 쓸 수 있습니다! /api도 빠졌어요.

• router.get("/kakao/end",()=>{}) 노파심에 적자면 redirect_uri랑 맞춰주셔야 하니까요. /users/kakao/end 라고 써야 테스트 될 것 같아요.

• 이렇게 적고 보니 /users 아래에 kakao router를 연결하려고 하셨을 수도 있겠다 싶긴해요.

• 완성이 안되서 빼신걸까요!?

• 적다보니 이거 빠졌어요, 저거 빠졌어요 이런 식으로 많이 적었네요. 다 되게 사소한 것들이지만 서버는 아무튼 정확함이 생명이니까요..! 특히 api 문서는 정말 별 거 아니게 느껴지시고, 왜 작성하는지 모르겠고.. 하시겠지만(아닐 수도 있지만 저는 옛날에 그랬거든요. 너무 작성하기 싫어가지고..) 프론트엔드랑 소통할 때 가장 중요한 문서니까요! 나중에 그 소중함을 더 느끼게 되실거에요. 또 요구사항은 정말 이렇게 만들라고 하는 가이드라인이기 때문에 맞춰서 만드는 것을 연습하시는 게 큰 도움이 됩니다. 그래서 지금 과제하신 내용이 틀렸다기 보다는 요구사항을 맞추지 못했으면 그걸 맞춰야한다는 피드백을 드리는 거에요!

• 끝까지 과제 마무리해주시고 또 피드백 내용도 다 적용하시고 찾아와서 알려주시고 하셔서 살짝 감동받았어요~ 연휴 잘 보내시고!! 화이팅하세요~!