[필수 포함 사항]
- READ.ME 작성
- 프로젝트 빌드, 자세한 실행 방법 명시
- 구현 방법과 이유에 대한 간략한 설명
- 완료된 시스템이 배포된 서버의 주소
- Swagger나 Postman을 통한 API 테스트할때 필요한 상세 방법
- 해당 과제를 진행하면서 회고 내용 블로그 포스팅
- Swagger나 Postman을 이용하여 API 테스트 가능하도록 구현
✔️ API 목록
- 거래내역 조회 API
- 입금 API
- 출금 API
✔️ 주요 고려 사항은 다음과 같습니다.
- 계좌의 잔액을 별도로 관리해야 하며, 계좌의 잔액과 거래내역의 잔액의 무결성의 보장
- DB를 설계 할때 각 칼럼의 타입과 제약
✔️ 구현하지 않아도 되는 부분은 다음과 같습니다.
- 문제와 관련되지 않은 부가적인 정보. 예를 들어 사용자 테이블의 이메일, 주소, 성별 등
- 프론트앤드 관련 부분
✔️ 제약사항은 다음과 같습니다.
- (8퍼센트가 직접 로컬에서 실행하여 테스트를 원하는 경우를 위해) 테스트의 편의성을 위해 mysql, postgresql 대신 sqllite를 사용해 주세요.
✔️ 상세설명
1) 거래내역 조회 API
- 아래와 같은 조회 화면에서 사용되는 API를 고려하시면 됩니다. https://lh6.googleusercontent.com/PdtI4YvVu3biJ0TyEGCHVrR0fAPOQsILYHEczQHmR3UMKEINxlIjjp_-3gOGu5yGh3YXpxbegNYqNCEosUosq3nKRTMpte6ZiRUccX8iRlD5rxLJ1HWFy6E2HcMFMIMGZO7eVQl5
거래내역 API는 다음을 만족해야 합니다.
- 계좌의 소유주만 요청 할 수 있어야 합니다.
- 거래일시에 대한 필터링이 가능해야 합니다.
- 출금, 입금만 선택해서 필터링을 할 수 있어야 합니다.
- Pagination이 필요 합니다.
- 다음 사항이 응답에 포함되어야 합니다.
- 거래일시
- 거래금액
- 잔액
- 거래종류 (출금/입금)
- 적요
2) 입금 API
입금 API는 다음을 만족해야 합니다.
- 계좌의 소유주만 요청 할 수 있어야 합니다.
3) 출금 API
출금 API는 다음을 만족해야 합니다.
- 계좌의 소유주만 요청 할 수 있어야 합니다.
- 계좌의 잔액내에서만 출금 할 수 있어야 합니다. 잔액을 넘어선 출금 요청에 대해서는 적절한 에러처리가 되어야 합니다.
4) 가산점
다음의 경우 가산점이 있습니다.
- Unit test의 구현
- Functional Test 의 구현 (입금, 조회, 출금에 대한 시나리오 테스트)
- 거래내역이 1억건을 넘어갈 때에 대한 고려
- 이를 고려하여 어떤 설계를 추가하셨는지를 README에 남겨 주세요.
프로젝트 자세히
회고
- 이번 과제는 API가 많지 않고 조건을 해결하는 게 중점인 문제이다. 첫번째로 고려해야 할 문제는 데이터의 무결성이다. 두번째는 거래내역이 1억건을 넘어갈 때에 대한 고려사항이다. 우선 데이터의 무결성은 sequelize의 transaction을 이용했다. sequelize의 transaction은 2가지 방식이 있다.
Unmanaged transactions: 커밋과 롤백이 별도의 메소드에 의해 직접 호출되어야 하는 트랜잭션
Managed transactions: 별 문제가 없으면 Sequelize가 자동으로 커밋해주고, 만약 중간에 에러가 발생하면 롤백시키는 트랜잭션
이 중 unmanaged transactions를 이용했다.
두번째에 대한 고려사항은 크게 4가지였다. 프로젝트 자세히에 가보며 REAME에 팀원분이 자세히 적어주셨다. 적용한 부분만 간단히 정리하자면 기본 execution plan는 불안전하기 때문에 서브쿼리를 이용하여 효율적으로 검색하도록 했다. offset-limit의 페이지네이션 대신 이전 페이지의 마지막 row를 cookie를 통해 전달하여 이후의 값을 불러오게 하여 불필요한 요청을 없애 효율적인 검색을 이루었다.
기록
- raw가 true인 경우, Sequelize는 쿼리 결과의 형식을 지정하거나 결과에서 모델의 인스턴스를 빌드하지 않습니다.
정리노트