Oracle의 경우 start with 문을 사용해서 간단하게 계층형쿼리를 출력할 수 있지만
MySQL에서는 start with 를 사용할 수 없다.
그렇기 때문에 이전 게시글에서 프로시저를 하나 만들었었다.
GetFamilyTree라는 프로시저는 인수를 하나 받는데,
인수의 값과 멤버아이디와 같은 데이터가 시작노드이다.
API는 로우쿼리를 사용해서 프로시저를 호출하고 있다.
데이터는 잘 받아 온다.
요번 프로젝트는 API 명세서 작성을 스웨거를 사용함으로써 대체하려한다.
스웨거로 대체하고싶은 이유는 저번 프로젝트에서의 경험 때문이다.
API명세서를 따로 작성하면 초반에만 변경사항에 대해 꼼꼼히 수정을 하지만, 시간이 지날수록 코드의 수정사항 또는 처음에는 생각하지 못한 추가적인 메소드들에 대해서 다 적어주지 못했다.
스웨거는 소스코드에서 설정하기 때문에 따로 관리할 필요 없이 코드를 적을때 데코레이터 등으로 같이 적어주면 된다.
그래서 스웨거를 사용하기로 했지만 고민거리가 생겼다.
예를 들어 구글독스나, 엑셀, 표 등을 이용한 API명세서 에서는
예외 상황 시 어떤 상태코드를 주는지 적혀져 있다.
그러나 스웨거는 그런게 적혀있지 않다.
이 문제를 어떻게 해결할까 고민을 해보다
@nestjs/swagger에서 제공하는 ApiResponse 데코레이터를 알게 되었다.
이 데코레이터를 사용하면 어떤 예외 사항에 어떤 코드가 나온다를 표현할 수 있다.
@ApiResponse({ status: 444, description: '호호아줌마가 나타나는 경우' })
그런데 만약 예외사항이 여러개 이고,
또한 API들이 여러개 있고 그 API들도 예외사항이 여러개라면
코드는 정말 복잡할것같다는 생각이 들었다.
그래서 조금이라도 줄을 줄여보자는 생각에
{ status: 444, description: '호호아줌마가 나타나는 경우' }
이 객체를 따로 저장해서 import해서 사용을 해보자 라는 생각이 들었고
코드를 작성해보았다.
이렇게 줄여보니 훨씬 좋았다.
하!지!만! 아직 예외상황이 여러개일때는 처리되지 않았다.
예외가 여러개일 때는 ApiResponse 데코레이터를 각 예외마다 한번씩 호출해야 한다.
또 어떻게 할까 고민을 해보다 나의 사랑 이성일 대장님 에게 도움을 받아
Decorator composition 를 알게 되었다.
applyDecorators 데코레이터는 여러 데코레이터를 결합해준다.
applyDecorators(ApiResponse(), ApiResponse(), ...)
뭐 이런식이다.
그런데, 각 ApiResponse데코레이터들에 파라미터를 어떻게 주입시킬까를 고민해봤다.
만약 커스텀 데코레이터를 여러개 만들어서 상황에 맞는 곳에서만 사용한다면
결국 커스텀 데코레이터는 계속 늘어날 수 있다.
그래서 나는 배열안에 인자를 머금은 ApiResponse를 저장시키고 그걸 applyDecorators에 풀기로 했다.
짜잔~~~슨☆★
이제 스웨거로도 예외 상황을 표현할 수 있게 됐다.
다음번은 프론트 작업인데.. 받은 데이터를 조직도로 표현을 해야한다.
아... 난 정말 프론트가 너무 어려워....
그래도 뭐.. 혼자하는데.. 해야지.. 후.. 이기회에 좀 음... 화이팅..
