[최은비] sprint10

[silverraining]

배포 URL

https://mission10-be.onrender.com/

Swagger docs

https://mission10-be.onrender.com/api-docs/

프로젝트 요구사항

기본 요구사항

• 공통
  • GitHub에 위클리 미션 PR을 만들어 주세요.
  • React.js 혹은 Next.js를 사용해 진행합니다.
  • RESTful을 설계하고 백엔드 코드를 변경하세요.
  • 설계한 백엔드 코드에 맞게 프론트엔드 코드를 변경해 주세요.
  • Panda Market API를 사용한 코드를 본인의 백엔드 API 코드로 변경하세요.
  • 프론트엔드 코드에 맞게 백엔드 코드를 변경해 주세요.
  • 백엔드 코드에 swagger를 추가해 API 명세 문서를 생성해 주세요.

백엔드 구현 요구사항

상품 등록

• "상품 등록하기" 버튼 클릭 시, 상품 정보 등록 API 엔드포인트에 요청을 보내 상품을 등록합니다.
• 상품 등록 시 필요한 필드(이름, 설명, 가격 등)의 유효성을 검증하는 미들웨어를 구현합니다.
• multer 미들웨어를 사용하여 이미지 업로드 API를 구현해 주세요.
• 업로드된 이미지는 서버에 저장하고, 해당 이미지의 경로를 response 객체에 포함해 반환합니다.

상품 상세

• 상품을 조회할 때, 해당 상품에 대한 댓글 리스트, 사용자가 '좋아요'를 눌렀는지 여부를 확인할 수 있도록 응답 객체에 포함시켜 반환해 주세요.

좋아요 기능

• '좋아요' API를 만들어 주세요.
  • 사용자는 상품 또는 게시글에 '좋아요'를 할 수 있습니다.
  • $transaction을 사용해 주세요.
• '좋아요' 취소 API를 만들어 주세요.
  • 사용자는 상품 또는 게시글에 '좋아요'를 취소할 수 있습니다.
  • $transaction을 사용해 주세요.
• 상품 또는 게시글을 조회할 때, 사용자가 '좋아요'를 누른 항목인지 확인할 수 있도록 isLiked 필드를 응답 객체에 포함시켜 반환해 주세요.

에러 처리

• 모든 예외 상황을 처리할 수 있는 에러 핸들러 미들웨어를 구현합니다.
• 서버 오류(500), 사용자 입력 오류(400 시리즈), 리소스 찾을 수 없음(404) 등 상황에 맞는 상태값을 반환합니다.

라우트 중복 제거

• 중복되는 라우트 경로(예: /users에 대한 get 및 post 요청)를 app.route()로 통합해 중복을 제거합니다.
• express.Router()를 활용하여 중고마켓/자유게시판 관련 라우트를 별도의 모듈로 구분합니다.

인증

• User 스키마를 작성해 주세요.
  • id, email, nickname, image, encryptedPassword, createdAt, updatedAt 필드를 가집니다.
• 회원가입 API를 만들어 주세요.
  • email, nickname, password를 입력하여 회원가입을 진행합니다.
  • password는 해싱해 저장합니다.
• 로그인 API를 만들어 주세요.
  • 사용자의 신원을 확인하고, 성공적인 인증 후에는 액세스 토큰을 발급해 response 객체에 포함해 반환합니다.

상품 기능 인가

• 로그인한 사용자만 상품을 등록할 수 있습니다.
• 상품을 등록한 사용자만 해당 상품의 정보를 수정 및 삭제를 할 수 있습니다.
• 로그인한 사용자만 상품에 '좋아요'를 추가하거나 삭제할 수 있습니다.

게시글 기능 인가

• 로그인한 사용자만 게시글을 등록할 수 있습니다.
• 게시글을 등록한 사용자만 해당 게시글 정보를 수정 및 삭제할 수 있습니다.
• 로그인한 사용자만 게시글에 '좋아요'를 추가하거나 삭제할 수 있습니다.

댓글 기능 인가

• 로그인한 사용자만 상품에 댓글을 등록할 수 있습니다.
• 로그인한 사용자만 게시글에 댓글을 등록할 수 있습니다.
• 댓글을 등록한 사용자만 댓글을 수정하거나 삭제할 수 있습니다.

멘토에게

• 실수로 copilot을 리뷰어로 설정했더니 자동으로 closed 되어버려서 다시 PR 올립니다.
• 백엔드 배포는 render로 하면 된다는걸 깜빡하고 vercel로 둘다 해보려고하다가 한참을 헤맸습니다(tmi...) 찾아보니 express 프로젝트도 vercel로 배포는 가능 한 것 같은데 잘 쓰지는 않는 조합인가요? 결국 백엔드는 그나마 익숙한 render로 배포했습니다.
• 백엔드가 에러핸들링을 미들웨어로 넘기고 상태코드에 따라서 적절히 처리하되 중복되지 않도록 처리하고.. 등 신경쓸 것이 정말 많다는 것을 깨달았습니다. 미들웨어를 어떻게사용할 것인지 라우터, 컨트롤러, 서비스중 어디에서 처리하게 할 것인지 어느 파일에 코드를 작성해야하는지 등 의 고민이 있었습니다. 더 알아보고 적용해보면서 익혀야할 것 같습니다.
• MVC 패턴이나 Layered Architecture와 같은 설계 방식의 best practice가 궁금합니다.

[rjc1704]

은비님 스프린트 10 백엔드 과제도 잘 수행해주셨습니다!
아래 코멘트를 달아드리겠습니다.

• "express 프로젝트도 vercel로 배포는 가능 한 것 같은데 잘 쓰지는 않는 조합인가요?" -> 네 굳이 express 를 서버리스 환경에서만 동작하는 vercel 에 배포하실 필요는 없습니다. 반면 render.com 의 경우 무료플랜은 vercel 과 마찬가지로 서버리스 환경으로 배포되지만, 추후 유료플랜으로 변경 시 항상 켜져있는 fully managed 서버로 쉽게 전환할 수 있습니다. 파트4에서 AWS 배우시면 거의 무료로 fully managed 서버를 배포하는 것에 대해서 배우실테니 그전까지는 서버리스 환경에서만 동작하는 서버로 만족해야겠습니다.
• "MVC 패턴이나 Layered Architecture와 같은 설계 방식의 best practice가 궁금합니다."
  -> MVC 패턴은 Layered Architecture의 일종입니다. 아래 두 가지 접근법 모두 코드의 관심사 분리를 통해 유지보수성과 확장성을 높이는 것이 목표입니다. 규모가 작은 프로젝트(예: 학습용, 소규모 API)의 경우: Express에서는 전통적인 MVC를 확장하여 다음과 같은 구조를 많이 사용합니다. 이 구조는 배우기 쉽고 작은 규모에서 충분히 효과적입니다.

routes: URL 경로와 HTTP 메서드 정의 (라우팅)
controllers: 요청 처리 로직 (입력 검증, 응답 형식화)
services: 비즈니스 로직 (모델 조작, 여러 데이터 소스 통합)
models: 데이터 구조와 데이터 접근 로직

큰 규모의 프로젝트(확장성 중요)의 경우: 도메인 중심 설계(DDD)가 더 효과적입니다. NestJS의 모듈 구조와 유사하며, 도메인별로 관련 코드가 함께 있어 확장에 유리합니다.

src/
  domains/
    users/
      user.controller.js
      user.service.js
      user.model.js
      user.route.js
    products/
      product.controller.js
      product.service.js
      product.model.js
      product.route.js
  shared/
    middlewares/
    utils/
    config/

아키텍처를 정할 때 Best Practice 가 있기 보다는 위와 같은 구조로 프로젝트를 진행했을 때 관리해야하는 파일수가 몇개나 필요하고 폴더 내에서 파일이 많이 늘어난다면 어떤 구조가 더 유리할지, 우리 팀에서는 현재 프로젝트를 진행할 때 어떤 부분이 더 좋을 지를 생각해보고 결정하는 것이 좋습니다. 중요한 건 제3자에게 명확하게 책임구분을 기반으로 아키텍처에 대해 설명할 수 있는 규칙과 기준이 있어야 하는데, 일반적으로 코드베이스의 규모, 함께 작업할 팀원들 간의 숙련도 및 러닝커브 등을 고려해서 결정하게 됩니다. express 에서는 보통 위 2가지 아키텍처를 일반적으로 자주 사용합니다.

• 스키마를 보니 테이블 관계설정을 하지 않으셨군요. 관계설정이 없으면 수정, 삭제 시 모델간 데이터간 정합성 관리가 어렵습니다. postgreSQL 사용하실 때 꼭 관계설정을 공부해서 진행하시는 것을 강력하게 권장 드립니다. 중급 프로젝트 때 어려우시면 고급 프로젝트 때는 ERD에 따라 관계맺고 의미를 설명할 수 있는 정도로 성장하셔야 합니다. 할 수 있습니다!
• 스웨거를 통한 api 문서 정리 아주 좋습니다! 고생하셨네요
• 각 도메인별 route.ts 에서 controller 앞에 req.body 에 대한 유효성검사를 진행하는 미들웨어를 추가해주시면 더 좋을 것 같습니다. get메소드를 제외한 나머지 메소드들에는 적용하면 좋겠고 유효성검사 시 superstruct 라이브러리 사용할 수 있게 미들웨어함수를 구성하시면 좋을 것 같습니다.
• app.js 에서 morgan 미들웨어를 통해서 각 요청에 대해 서버 내 로그가 찍힐 수 있게 처리하는 것을 기본설정으로 생각해주는 것을 권장 드립니다.

[silverraining]

은비님 스프린트 10 백엔드 과제도 잘 수행해주셨습니다! 아래 코멘트를 달아드리겠습니다.

• "express 프로젝트도 vercel로 배포는 가능 한 것 같은데 잘 쓰지는 않는 조합인가요?" -> 네 굳이 express 를 서버리스 환경에서만 동작하는 vercel 에 배포하실 필요는 없습니다. 반면 render.com 의 경우 무료플랜은 vercel 과 마찬가지로 서버리스 환경으로 배포되지만, 추후 유료플랜으로 변경 시 항상 켜져있는 fully managed 서버로 쉽게 전환할 수 있습니다. 파트4에서 AWS 배우시면 거의 무료로 fully managed 서버를 배포하는 것에 대해서 배우실테니 그전까지는 서버리스 환경에서만 동작하는 서버로 만족해야겠습니다.
• "MVC 패턴이나 Layered Architecture와 같은 설계 방식의 best practice가 궁금합니다."
  -> MVC 패턴은 Layered Architecture의 일종입니다. 아래 두 가지 접근법 모두 코드의 관심사 분리를 통해 유지보수성과 확장성을 높이는 것이 목표입니다. 규모가 작은 프로젝트(예: 학습용, 소규모 API)의 경우: Express에서는 전통적인 MVC를 확장하여 다음과 같은 구조를 많이 사용합니다. 이 구조는 배우기 쉽고 작은 규모에서 충분히 효과적입니다.

routes: URL 경로와 HTTP 메서드 정의 (라우팅) controllers: 요청 처리 로직 (입력 검증, 응답 형식화) services: 비즈니스 로직 (모델 조작, 여러 데이터 소스 통합) models: 데이터 구조와 데이터 접근 로직

큰 규모의 프로젝트(확장성 중요)의 경우: 도메인 중심 설계(DDD)가 더 효과적입니다. NestJS의 모듈 구조와 유사하며, 도메인별로 관련 코드가 함께 있어 확장에 유리합니다.

src/
  domains/
    users/
      user.controller.js
      user.service.js
      user.model.js
      user.route.js
    products/
      product.controller.js
      product.service.js
      product.model.js
      product.route.js
  shared/
    middlewares/
    utils/
    config/

아키텍처를 정할 때 Best Practice 가 있기 보다는 위와 같은 구조로 프로젝트를 진행했을 때 관리해야하는 파일수가 몇개나 필요하고 폴더 내에서 파일이 많이 늘어난다면 어떤 구조가 더 유리할지, 우리 팀에서는 현재 프로젝트를 진행할 때 어떤 부분이 더 좋을 지를 생각해보고 결정하는 것이 좋습니다. 중요한 건 제3자에게 명확하게 책임구분을 기반으로 아키텍처에 대해 설명할 수 있는 규칙과 기준이 있어야 하는데, 일반적으로 코드베이스의 규모, 함께 작업할 팀원들 간의 숙련도 및 러닝커브 등을 고려해서 결정하게 됩니다. express 에서는 보통 위 2가지 아키텍처를 일반적으로 자주 사용합니다.

• 스키마를 보니 테이블 관계설정을 하지 않으셨군요. 관계설정이 없으면 수정, 삭제 시 모델간 데이터간 정합성 관리가 어렵습니다. postgreSQL 사용하실 때 꼭 관계설정을 공부해서 진행하시는 것을 강력하게 권장 드립니다. 중급 프로젝트 때 어려우시면 고급 프로젝트 때는 ERD에 따라 관계맺고 의미를 설명할 수 있는 정도로 성장하셔야 합니다. 할 수 있습니다!
• 스웨거를 통한 api 문서 정리 아주 좋습니다! 고생하셨네요
• 각 도메인별 route.ts 에서 controller 앞에 req.body 에 대한 유효성검사를 진행하는 미들웨어를 추가해주시면 더 좋을 것 같습니다. get메소드를 제외한 나머지 메소드들에는 적용하면 좋겠고 유효성검사 시 superstruct 라이브러리 사용할 수 있게 미들웨어함수를 구성하시면 좋을 것 같습니다.
• app.js 에서 morgan 미들웨어를 통해서 각 요청에 대해 서버 내 로그가 찍힐 수 있게 처리하는 것을 기본설정으로 생각해주는 것을 권장 드립니다.

우와 자세한 설명 감사합니다 멘토님 ! 👍 저희 지난주 멘토링 이후에 바로 프로젝트에 DB 관계설정 적용하였습니다 :) 멘토링 시간에 질문 이어가도록하겠습니다 . 감사합니다 ~~