[TIL] 원티드 프리온보딩 백엔드 인턴십 Week3) 17일차, 0905

✔️ 오늘 한 일

고민한 내용
- 각 주문상태의 업데이트 기준을 어떻게 설정할 것인가?
  * 상태 예시) 주문완료, 입금완료, 송금완료, 수령완료, 발송완료
분석
- 내 의견 : 앞 단계가 완료되면 다음 단계로 자동으로 상태가 변경되도록 설정
  (단, 각 단계의 완료 기준을 어떻게 정의할지 추가 고려 필요)
- 팀원분 의견 : 입금-발송, 송금-수령 완료 사이에 검수 단계를 두고, 판매자, 구매자, 관리자가 각 권한에 따라 상태를 변경할 수 있도록 설정
결론
- 모든 주문상태는 관리자만 변경할 수 있도록 하는 것이 적절하다는 결론에 도달했다.
- 자동 상태 변경을 적용하려면 결제 시스템의 완전한 자동화가 필요하기 때문에 무리가 있다고 판단했다.
  * 자동화가 어려운 이유 : 금 거래 시, 직접 계좌이체나 현금 거래를 선호하는 경우가 있어 완벽한 자동 결제 시스템을 적용하기 어려울 수 있다.
- 판매자와 구매자가 상태를 직접 변경하는 부분은, 사용자가 의도적으로 잘못된 정보를 입력하거나 실수로 잘못된 상태를 입력할 가능성이 있기 때문에 관리자만 변경할 수 있도록 제한하는 것이 적절하다고 판단했다. 대신 검수 단계 추가는 유의미하다고 판단해 고려하기로 했다.

프론트엔드에서 필요한 데이터를 쿼리 형태로 작성해 백엔드에 요청하고, 원하는 데이터만 받아올 수 있다.
(기존 Rest API는 백엔드가 미리 정의한 데이터만 받을 수 있어 자유도가 낮았다.)
장점
- 클라이언트가 필요한 데이터만 선택적으로 요청할 수 있어 효율적이다.
- 엔드포인트가 줄어들고 데이터 요청이 명확해져 코드가 간결해질 수 있다.
단점
- 초기 학습 난이도가 높다.
- 모든 데이터를 요청할 수 있어 보안에 취약할 수 있다.

< 해당 글은 velog에서 이전하며 옮겨온 글로, 가독성이 좋지 않을 수 있는 점 양해 부탁드립니다. >