테이블 설계, 회의해야 할 것 같아요.
출고의 메인이 되는 테이블에 대한 변형이 필요한 상태였다.
현재는 국내 출고를 위한 테이블이 존재하고
해외 출고를 위한 테이블의 설계를 하고 있었는데
두 개의 테이블로 분리할 경우, 기존 출고 프로세스에 큰 영향을 줄 것이라 판단하여
모든 인원이 출근하는 월요일에 회의를 하고 결정하기로 했다.
NestJS 답게 사용하기.
현재 출고 모듈이 매우 비대하다.
출고에 관여되는 모든 서비스들이 다 모여져있다보니 이러한 현상이 발생했는데(...)
덕분에 테스트코드를 짤 때 마다, 수많은 종속성에 머리가 아파와지는 일이 발생했다.
어짜피 다음주 월요일까지 테이블 설계 때문에 진행을 못하니, 이 참에 리팩토링을 하는 것이 좋겠다 라는 생각에 모듈 단위로 쪼개는 작업을 진행했다.
같은 status 번호에 여러개 집어넣기.
도메인이 물류다보니 검증하는 로직이 매우 많다.
그러면서 에러핸들링도 상당히 많은 과정이 들어가있는데
여기서 발견한 문제가 있었다.
한개의 status 번호에 여러개의 response example을 넣을 수 없다는 것.
이러한 문제로 발생하는 것은.....
FE 입장에서 노션 등을 확인해야지만 에러를 확인할 수 있다.
가능하면 스웨거로 전부 다 할 수 있으면 좋겠다 싶어서 찾아봤더니
되긴 되더라(!)
export const ApiHttpExceptionResponse = (statusCode: number, errorCode: Description[]): any => {
const data: (SchemaObject | ReferenceObject)[] = errorCode.map((val) => {
return { title: val.title, description: val.description };
});
return applyDecorators(
ApiResponse({
status: statusCode,
description: 'Schema를 참고하세요.',
schema: {
anyOf: data,
},
})
);
};실제 컨트롤러 단에서는 이렇게 표기를 해서 사용할 수 있다.
@ApiHttpExceptionResponse(400, [ErrorDesc.E4002, ErrorDesc.E4008, ErrorDesc.E4021, ErrorDesc.E4052, ErrorDesc.E4053])에러독스라는 것을 따로 선언해서 관리를 하는 것이지만
프론트가 스웨거만으로 모든 작업을 할 수 있도록 하는 것..
FE와 BE의 커뮤니케이션 비용을 줄이기 위하여 이런저런 것들을 해보고있다.
아, 내일과 모레는 연차라서 일기가 없을 것이고
개발자로 처음 써보는 년 회고가 있을 것 같다.
